Time to retire some ancient network pseudo-interfaces?

[Jason Thorpe]

Hey folks --

I think it's time to retire some of the ancient network pseudo-interfaces that still linger in our tree. Specifically, strip and sl.

-- strip -- Starmode Radio IP -- this was an operation mode of the Metricom Ricochet radios back in the mid-to-late-90s. Metricom is no longer around, and I seriously doubt anyone is using these radios anymore. (I tossed mine in an e-recycling bin many years ago.)

-- sl -- SLIP, or Serial Line IP -- This was ancient and crufty even in the 90s, as it had been obsoleted even then by PPP over serial lines. I think the main users of SLIP on NetBSD were folks with pc532s (you could count the number of those people on one hand) as those systems had only serial lines[*] for communicating to the outside world ([*] Well, technically, I think a few people might have had a Cabletron SCSI-to-Ethernet interface, but that only reinforces my point :-) In any case, pc532 has been relegated to the Attic, and I think SLIP should be, as well.

Thoughts?

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Andy Ball]

Hello Jason,

JT> I think it's time to retire some of the ancient network pseudo-

Post by Jason Thorpe
interfaces that still linger in our tree. Specifically, strip
and sl.

SLIP is still handy (if slow) for talking to equipment that lacks
a working Ethernet port. It might be handy for some of the embedded
applications that NetBSD is well suited to. I don't imagine it's very
large. Is it broken or otherwise a burden?

Thanks,
-Andy Ball

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Post by Andy Ball
Hello Jason,
JT> I think it's time to retire some of the ancient network pseudo-

Post by Jason Thorpe
interfaces that still linger in our tree. Specifically, strip
and sl.

SLIP is still handy (if slow) for talking to equipment that lacks
a working Ethernet port. It might be handy for some of the embedded
applications that NetBSD is well suited to. I don't imagine it's very
large. Is it broken or otherwise a burden?

It's a burden in the sense that it's another item of extremely limited utility that has to be modified in the continuing quest to modernize the NetBSD networking stack.

As for use with embedded systems, I can't imagine that it's really all that useful in that scenario; many of the UARTs on such devices lack flow control signals, so the reliability of the interface would be of concern. There are typically (and, these days, universally) better ways to connect to embedded systems. Honestly, the first thing that leapt to mind for a contemporary use of SLIP was "some poor soul might have a VAX 11/7x0 that without an Ethernet interface".

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jonathan A. Kollasch]

Post by Jason Thorpe
Hey folks --
I think it's time to retire some of the ancient network pseudo-interfaces that still linger in our tree. Specifically, strip and sl.
-- strip -- Starmode Radio IP -- this was an operation mode of the Metricom Ricochet radios back in the mid-to-late-90s. Metricom is no longer around, and I seriously doubt anyone is using these radios anymore. (I tossed mine in an e-recycling bin many years ago.)
-- sl -- SLIP, or Serial Line IP -- This was ancient and crufty even in the 90s, as it had been obsoleted even then by PPP over serial lines. I think the main users of SLIP on NetBSD were folks with pc532s (you could count the number of those people on one hand) as those systems had only serial lines[*] for communicating to the outside world ([*] Well, technically, I think a few people might have had a Cabletron SCSI-to-Ethernet interface, but that only reinforces my point :-) In any case, pc532 has been relegated to the Attic, and I think SLIP should be, as well.

I would sooner not see SLIP support disappear already. There are, for
instance, old 3Com Fast Ethernet managed switches (like the 3C16980 I
have sitting around still) that implement SLIP for access to their web
interface. It's probably easier to keep it with the existing sl(4) than
to reimplement it via tun(4) and a hypothetical sliptun(8).

Jonathan Kollasch

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Post by Jonathan A. Kollasch

Post by Jason Thorpe
Hey folks --
I think it's time to retire some of the ancient network pseudo-interfaces that still linger in our tree. Specifically, strip and sl.
-- strip -- Starmode Radio IP -- this was an operation mode of the Metricom Ricochet radios back in the mid-to-late-90s. Metricom is no longer around, and I seriously doubt anyone is using these radios anymore. (I tossed mine in an e-recycling bin many years ago.)
-- sl -- SLIP, or Serial Line IP -- This was ancient and crufty even in the 90s, as it had been obsoleted even then by PPP over serial lines. I think the main users of SLIP on NetBSD were folks with pc532s (you could count the number of those people on one hand) as those systems had only serial lines[*] for communicating to the outside world ([*] Well, technically, I think a few people might have had a Cabletron SCSI-to-Ethernet interface, but that only reinforces my point :-) In any case, pc532 has been relegated to the Attic, and I think SLIP should be, as well.

I would sooner not see SLIP support disappear already. There are, for
instance, old 3Com Fast Ethernet managed switches (like the 3C16980 I
have sitting around still) that implement SLIP for access to their web
interface. It's probably easier to keep it with the existing sl(4) than
to reimplement it via tun(4) and a hypothetical sliptun(8).

Fair enough -- consider my proposal to remove SLIP abandoned.

My stance on STRIP stands, though :-)

Post by Jonathan A. Kollasch
Jonathan Kollasch

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

I know you saw objections to SLIP removal and withdrew the proposal, but
for the record I too would like it to stay. It's really longstanding
and simple, and I don't think it hurts much. With the brave new world
of tiny microcontrollers the idea that something else does slip and not
ppp is not crazy.

[Jason Thorpe]

Post by Greg Troxel
I know you saw objections to SLIP removal and withdrew the proposal, but
for the record I too would like it to stay. It's really longstanding
and simple, and I don't think it hurts much. With the brave new world
of tiny microcontrollers the idea that something else does slip and not
ppp is not crazy.

Yes, certainly SLIP would be more appropriate than PPP for running on, say, an AVR.

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Kamil Rytarowski]

Post by Jason Thorpe
Hey folks --
I think it's time to retire some of the ancient network pseudo-interfaces that still linger in our tree. Specifically, strip and sl.
-- strip -- Starmode Radio IP -- this was an operation mode of the Metricom Ricochet radios back in the mid-to-late-90s. Metricom is no longer around, and I seriously doubt anyone is using these radios anymore. (I tossed mine in an e-recycling bin many years ago.)
-- sl -- SLIP, or Serial Line IP -- This was ancient and crufty even in the 90s, as it had been obsoleted even then by PPP over serial lines. I think the main users of SLIP on NetBSD were folks with pc532s (you could count the number of those people on one hand) as those systems had only serial lines[*] for communicating to the outside world ([*] Well, technically, I think a few people might have had a Cabletron SCSI-to-Ethernet interface, but that only reinforces my point :-) In any case, pc532 has been relegated to the Attic, and I think SLIP should be, as well.
Thoughts?
-- thorpej

sl might be useful on unuseful hardware.

I've noted interest in sl around users for the last time like 2 years ago.

strip I would keep it around as it's harmless.

[Anders Magnusson]

Post by Jason Thorpe
Hey folks --
I think it's time to retire some of the ancient network pseudo-interfaces that still linger in our tree. Specifically, strip and sl.
-- strip -- Starmode Radio IP -- this was an operation mode of the Metricom Ricochet radios back in the mid-to-late-90s. Metricom is no longer around, and I seriously doubt anyone is using these radios anymore. (I tossed mine in an e-recycling bin many years ago.)
-- sl -- SLIP, or Serial Line IP -- This was ancient and crufty even in the 90s, as it had been obsoleted even then by PPP over serial lines. I think the main users of SLIP on NetBSD were folks with pc532s (you could count the number of those people on one hand) as those systems had only serial lines[*] for communicating to the outside world ([*] Well, technically, I think a few people might have had a Cabletron SCSI-to-Ethernet interface, but that only reinforces my point :-) In any case, pc532 has been relegated to the Attic, and I think SLIP should be, as well.

I too would want slip to stay.  I occasionally use it due to its
simplicity (don't hit me! *ducks*)

-- Ragge

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Post by Kamil Rytarowski
strip I would keep it around as it's harmless.

But what purpose would that serve?

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Kamil Rytarowski]

Post by Jason Thorpe

Post by Kamil Rytarowski
strip I would keep it around as it's harmless.

But what purpose would that serve?
-- thorpej

Certainly limited, but occasionally people test such drivers and
devices, others take inspiration from them.

[Jason Thorpe]

Post by Kamil Rytarowski

Post by Jason Thorpe

Post by Kamil Rytarowski
strip I would keep it around as it's harmless.

But what purpose would that serve?
-- thorpej

Certainly limited, but occasionally people test such drivers and
devices, others take inspiration from them.

1- No one can test STRIP ... I mean, really, I am pretty sure no one has one of these radios anymore, and it's a firm requirement.

2- STRIP took its inspiration from SLIP, and I have withdrawn my proposal to remove that.

STRIP is quite possibly the deadest wood in the tree at this point.

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by David Young

Post by Jason Thorpe
1- No one can test STRIP ... I mean, really, I am pretty sure no one has one of these radios anymore, and it's a firm requirement.

I have the radios. I will see if I can even get them to work.

And I don't think that just because I have the radios, we should keep
the driver. But if my radios are the only ones known to anyone, and
they're not even viable, then that's strengthening the argument for
dropping the driver.

Dave

[Ryota Ozaki]

Post by Kamil Rytarowski

Post by Jason Thorpe
STRIP is quite possibly the deadest wood in the tree at this point.

I defer decisions from myself. I just personally see no gain in removals
of drivers, unless it helps something like removal of quirks.

Removing a component, even if it's small, is still useful for developers of
networking stuffs. We're sometimes annoyed by old, unmaintained codes
when we need to touch every network components because such codes
are often written in old fashion and difficult to touch (one noticeable
example is sys/dev/pci/if_lmc.c). Also if we want to turn NET_MPSAFE
on by default, all network components have to be taken care, so reducing
the number of components just makes the goal close.

Note that I don't say we should get rid of the components. What I want
to say is that if you want to leave some codes please keep them fine :-)

ozaki-r

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Post by Ryota Ozaki
Removing a component, even if it's small, is still useful for developers of
networking stuffs. We're sometimes annoyed by old, unmaintained codes
when we need to touch every network components because such codes
are often written in old fashion and difficult to touch (one noticeable
example is sys/dev/pci/if_lmc.c). Also if we want to turn NET_MPSAFE
on by default, all network components have to be taken care, so reducing
the number of components just makes the goal close.

Yes, that's exactly my point. There is a ton of dead wood in there that just needs to go. if_lmc.c is another perfect example.

Other examples off the top of my head:

- The Midway ATM driver and the associated netnatm stack.
- The RoadRunner HIPPI driver and associated if_hippisubr (even though that one is near and dear to my heart).
- We still have Matt Thomas's original "de" Tulip driver, which was long ago supplanted by if_tlp.c (which supports more device flavors and more bus attachments)
- There are some ISA Ethernet drivers that don't support even basic features required by modern network protocols (e.g. the "eg" driver that doesn't support multicast, for example).
- The Tropic Token Ring driver and associated if_tokensubr
- Same argument could probably be made for the FDDI stuff.

We made the hard decision to do a pruning with a couple of **platforms** (pc532, arm26, sh5 are the ones that leap to mind). If we have a platform on a lower support tier that can still reasonably use some of these things, there's always the attic if they want to resurrect them. But at some point to have to start pruning away just to maintain a sane workload.

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Simon Burge]

We made the hard decision to do a pruning with a couple of **platforms** =
(pc532, [ ... ]

Weeps a small tear :(

Cheers,
Simon.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Taylor R Campbell]

Date: Thu, 12 Jul 2018 21:17:58 -0700
- There are some ISA Ethernet drivers that don't support even basic
features required by modern network protocols (e.g. the "eg" driver
that doesn't support multicast, for example).

If eg(4) is not a good example of a driver, then that's a missed
opportunity and we ought to throw it away and recycle the name!

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Kamil Rytarowski]

Post by Ryota Ozaki
Also if we want to turn NET_MPSAFE
on by default, all network components have to be taken care, so reducing
the number of components just makes the goal close.

NET_MPSAFE shall be enabled by default or set as the only option.
Pruning some old drivers that need massive blind changes is a reasonable
trade-off on the road to this goal. Is this the case with strip?

[Robert Elz]

Date: Fri, 13 Jul 2018 10:51:14 +0200
From: Kamil Rytarowski <***@gmx.com>
Message-ID: <e2d5f649-cb7e-a570-c75e-***@gmx.com>


| NET_MPSAFE shall be enabled by default or set as the only option.
| Pruning some old drivers [...]

If I have been following what is happening in that area (and I might have
missed something) the "some old drivers" is most of them ... I get the
impression that only a few (a very few) drivers have been converted
yet (enough for the relevant developers to test ... ie: the ones they need.)

It would be nice to hear that is not the case, and that almost all have
been converted though.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[m***@netbsd.org]

If you wait long enough you can get to prune a lot of ARM platforms.
They no longer have a compiler.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Post by m***@netbsd.org
If you wait long enough you can get to prune a lot of ARM platforms.
They no longer have a compiler.

?

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[triaxx]

Maybe stupid suggestion...

Could we maintain a DHM (Driver History Museum) file that indexes
hardware previously (but no more) supported and the last supporting
release?

For instance:
sl(4) on NetBSD-8 [jdoe 2018-MM-DD]
o pseudo-device sl
o Allow asynchronous serial lines to be used as IPv4 network
interfaces
using the SLIP protocol.
strip(4) on NetBSD-8 [sbob 2018-MM-DD]
o pseudo-device strip
o Take outbound network packets, encapsulates them using the
Metricom
"star mode" framing, and sends the packets out an RS-232
interface to a
Metricom Ricochet packet radio.

I sometimes recover old hardware and I like to test NetBSD on it (just
to validate the following assumption: "of course it runs!")

But I totally understand developers that pain to maintain prehistoric
stuffs just because I have one in the attic.

The idea would be: "if I want to play with my old device, I try to port
it to new interfaces but I need to know where are the old sources"

Post by Jason Thorpe

Post by Ryota Ozaki
Removing a component, even if it's small, is still useful for
developers of
networking stuffs. We're sometimes annoyed by old, unmaintained codes
when we need to touch every network components because such codes
are often written in old fashion and difficult to touch (one
noticeable
example is sys/dev/pci/if_lmc.c). Also if we want to turn NET_MPSAFE
on by default, all network components have to be taken care, so reducing
the number of components just makes the goal close.

Yes, that's exactly my point. There is a ton of dead wood in there
that just needs to go. if_lmc.c is another perfect example.
- The Midway ATM driver and the associated netnatm stack.
- The RoadRunner HIPPI driver and associated if_hippisubr (even though
that one is near and dear to my heart).
- We still have Matt Thomas's original "de" Tulip driver, which was
long ago supplanted by if_tlp.c (which supports more device flavors
and more bus attachments)
- There are some ISA Ethernet drivers that don't support even basic
features required by modern network protocols (e.g. the "eg" driver
that doesn't support multicast, for example).
- The Tropic Token Ring driver and associated if_tokensubr
- Same argument could probably be made for the FDDI stuff.
We made the hard decision to do a pruning with a couple of
**platforms** (pc532, arm26, sh5 are the ones that leap to mind). If
we have a platform on a lower support tier that can still reasonably
use some of these things, there's always the attic if they want to
resurrect them. But at some point to have to start pruning away just
to maintain a sane workload.
-- thorpej

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Kamil Rytarowski]

... or just leave it as it is until it's known to be broken.

Drivers are good for inspiration for newer code and help to maintain
better APIs. If done well, they are usually without overhead for newer code.

Post by triaxx
Maybe stupid suggestion...
Could we maintain a DHM (Driver History Museum) file that indexes
hardware previously (but no more) supported and the last supporting
release?
sl(4) on NetBSD-8 [jdoe 2018-MM-DD]
        o pseudo-device sl
        o Allow asynchronous serial lines to be used as IPv4 network
interfaces
          using the SLIP protocol.
strip(4) on NetBSD-8 [sbob 2018-MM-DD]
        o pseudo-device strip
        o Take outbound network packets, encapsulates them using the
Metricom
          "star mode" framing, and sends the packets out an RS-232
interface to a
          Metricom Ricochet packet radio.
I sometimes recover old hardware and I like to test NetBSD on it (just
to validate the following assumption: "of course it runs!")
But I totally understand developers that pain to maintain prehistoric
stuffs just because I have one in the attic.
The idea would be: "if I want to play with my old device, I try to port
it to new interfaces but I need to know where are the old sources"

Post by Ryota Ozaki
Removing a component, even if it's small, is still useful for developers of
networking stuffs.  We're sometimes annoyed by old, unmaintained codes
when we need to touch every network components because such codes
are often written in old fashion and difficult to touch (one noticeable
example is sys/dev/pci/if_lmc.c).  Also if we want to turn NET_MPSAFE
on by default, all network components have to be taken care, so reducing
the number of components just makes the goal close.

Yes, that's exactly my point.  There is a ton of dead wood in there
that just needs to go.  if_lmc.c is another perfect example.
- The Midway ATM driver and the associated netnatm stack.
- The RoadRunner HIPPI driver and associated if_hippisubr (even though
that one is near and dear to my heart).
- We still have Matt Thomas's original "de" Tulip driver, which was
long ago supplanted by if_tlp.c (which supports more device flavors
and more bus attachments)
- There are some ISA Ethernet drivers that don't support even basic
features required by modern network protocols (e.g. the "eg" driver
that doesn't support multicast, for example).
- The Tropic Token Ring driver and associated if_tokensubr
- Same argument could probably be made for the FDDI stuff.
We made the hard decision to do a pruning with a couple of
**platforms** (pc532, arm26, sh5 are the ones that leap to mind).  If
we have a platform on a lower support tier that can still reasonably
use some of these things, there's always the attic if they want to
resurrect them.  But at some point to have to start pruning away just
to maintain a sane workload.
-- thorpej

[David Young]

Post by Jason Thorpe
1- No one can test STRIP ... I mean, really, I am pretty sure no one has one of these radios anymore, and it's a firm requirement.

I have the radios. I will see if I can even get them to work.

Dave

[Kamil Rytarowski]

Post by Jason Thorpe
STRIP is quite possibly the deadest wood in the tree at this point.

I defer decisions from myself. I just personally see no gain in removals
of drivers, unless it helps something like removal of quirks.

[Tom Ivar Helbekkmo]

Post by Jason Thorpe
I think it's time to retire some of the ancient network
pseudo-interfaces that still linger in our tree. Specifically, strip
and sl.

Please don't take sl/ip away! I use it to hook my old Stride systems
running UniStride (and communicating amongst themselves over OmniNet) up
to the rest of my network. strip may be dependent on anctien hardware
that no longer exists, but we've all got serial ports... :)

-tih

[Manuel Bouyer]

Post by Jason Thorpe
Hey folks --
I think it's time to retire some of the ancient network pseudo-interfaces that still linger in our tree. Specifically, strip and sl.
-- strip -- Starmode Radio IP -- this was an operation mode of the Metricom Ricochet radios back in the mid-to-late-90s. Metricom is no longer around, and I seriously doubt anyone is using these radios anymore. (I tossed mine in an e-recycling bin many years ago.)
-- sl -- SLIP, or Serial Line IP -- This was ancient and crufty even in the 90s, as it had been obsoleted even then by PPP over serial lines. I think the main users of SLIP on NetBSD were folks with pc532s (you could count the number of those people on one hand) as those systems had only serial lines[*] for communicating to the outside world ([*] Well, technically, I think a few people might have had a Cabletron SCSI-to-Ethernet interface, but that only reinforces my point :-) In any case, pc532 has been relegated to the Attic, and I think SLIP should be, as well.
Thoughts?

Well, I'm still using slip, to connect a developement board with only serial
ports as working communication peripherals. I could probably use ppp but it's
heavier to setup, and probably to run.

I guess we could even run slip in a bootloader ...

[m***@m00nbsd.net]

We could easily retire etherip. It has never been enabled (worse: the
option was not even present and commented out before I added it a few
months ago), the code is shitty, buggy (eg watch the man page) and not
MP-safe.

Above all, the EtherIP spec (RFC3378) actually recommends dropping
EtherIP and using L2TP instead. We do have L2TP -- written by the
Japanese guys, so it works, it's MP-safe and everything.

Basically people should use L2TP, and I don't see many reasons for
keeping etherip, especially if it's low quality code. Retiring it would
also prune one "unprotected" entry from the TODO.smpnet list.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Gert Doering]

Hi,

Post by m***@m00nbsd.net
We could easily retire etherip. It has never been enabled (worse: the
option was not even present and commented out before I added it a few
months ago), the code is shitty, buggy (eg watch the man page) and not
MP-safe.
Above all, the EtherIP spec (RFC3378) actually recommends dropping
EtherIP and using L2TP instead. We do have L2TP -- written by the
Japanese guys, so it works, it's MP-safe and everything.

Does NetBSD has L2TPv3? "Basic" L2TP won't give you "Ethernet-over-IP",
which is the point of, uh, etherip.

(Of course you can do etherip things with openvpn in tap mode, but for
many setups this is just far heavier than "I need to transport ethernet
frames, I do not need to care about encryption or authentication because
this all happens inside a closed environment" - which is where I've used
etherip in the past, bridge together VLANs across an "unwilling" internal
infrastructure)

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany ***@greenie.muc.de

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Post by Gert Doering
Hi,

Post by m***@m00nbsd.net
We could easily retire etherip. It has never been enabled (worse: the
option was not even present and commented out before I added it a few
months ago), the code is shitty, buggy (eg watch the man page) and not
MP-safe.
Above all, the EtherIP spec (RFC3378) actually recommends dropping
EtherIP and using L2TP instead. We do have L2TP -- written by the
Japanese guys, so it works, it's MP-safe and everything.

Does NetBSD has L2TPv3?

Yes, see the man page.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Gert Doering]

Hi,

Post by Maxime Villard

Post by Gert Doering

Post by m***@m00nbsd.net
Above all, the EtherIP spec (RFC3378) actually recommends dropping
EtherIP and using L2TP instead. We do have L2TP -- written by the
Japanese guys, so it works, it's MP-safe and everything.

Does NetBSD has L2TPv3?

Yes, see the man page.

Uh. Yes, love to. Which one, exactly?

nbsd70$ man l2tp
man: no entry for l2tp in the manual.
nbsd70$ man l2tpv3
man: no entry for l2tpv3 in the manual.
nbsd70$ man L2TP
man: no entry for L2TP in the manual.
nbsd70$ man L2TPv3
man: no entry for L2TPv3 in the manual.
nbsd70$ apropos l2tpv3
apropos: No relevant results obtained.
Please make sure that you spelled all the terms correctly or try using better keywords.
nbsd70$ apropos l2tp
racoon.conf (5) configuration file for racoon
...is allowed for the special case of a single user connecting to a gateway using an iPhone. On an iPhone, L2TP over IPSEC only supports main mode with pre-shared keys (no certificates). Unfortunately racoon only supports pre-shared-key...

nbsd70$ uname -a
NetBSD nbsd70.ov.greenie.net 7.0.1 NetBSD 7.0.1 (GENERIC.201605221355Z) i386


gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany ***@greenie.muc.de

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Post by Gert Doering
Hi,

Post by Maxime Villard

Post by Gert Doering

Post by m***@m00nbsd.net
Above all, the EtherIP spec (RFC3378) actually recommends dropping
EtherIP and using L2TP instead. We do have L2TP -- written by the
Japanese guys, so it works, it's MP-safe and everything.

Does NetBSD has L2TPv3?

Yes, see the man page.

Uh. Yes, love to. Which one, exactly?
nbsd70$ man l2tp
man: no entry for l2tp in the manual.

Our L2TP code appeared in NetBSD 8.

https://man-k.org/man/NetBSD-current/4/l2tp?r=1&q=l2tp

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Stephen Borrill]

Post by Gert Doering

Post by m***@m00nbsd.net
We could easily retire etherip. It has never been enabled (worse: the
option was not even present and commented out before I added it a few
months ago), the code is shitty, buggy (eg watch the man page) and not
MP-safe.
Above all, the EtherIP spec (RFC3378) actually recommends dropping
EtherIP and using L2TP instead. We do have L2TP -- written by the
Japanese guys, so it works, it's MP-safe and everything.

Does NetBSD has L2TPv3? "Basic" L2TP won't give you "Ethernet-over-IP",
which is the point of, uh, etherip.
(Of course you can do etherip things with openvpn in tap mode, but for
many setups this is just far heavier than "I need to transport ethernet
frames, I do not need to care about encryption or authentication because
this all happens inside a closed environment" - which is where I've used
etherip in the past, bridge together VLANs across an "unwilling" internal
infrastructure)

Another option is L2 over ssh (i.e. ssh -o Tunnel=ethernet -w 0:0 -N
<dest> at client end and "PermitTunnel ethernet", plus a bridge and tap at
the server end).

[Maxime Villard]

Post by m***@m00nbsd.net
We could easily retire etherip. It has never been enabled (worse: the
option was not even present and commented out before I added it a few
months ago), the code is shitty, buggy (eg watch the man page) and not
MP-safe.
Above all, the EtherIP spec (RFC3378) actually recommends dropping
EtherIP and using L2TP instead. We do have L2TP -- written by the
Japanese guys, so it works, it's MP-safe and everything.
Basically people should use L2TP, and I don't see many reasons for
keeping etherip, especially if it's low quality code. Retiring it would
also prune one "unprotected" entry from the TODO.smpnet list.

So what's up? Are we fine? I will remove it soon...

Also, while I'm thinking about it, in terms of broken/unused interfaces
we also have NDIS, which I guess should be marked as "unprotected" in
TODO.smpnet, too.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Post by Maxime Villard

Post by m***@m00nbsd.net
We could easily retire etherip. It has never been enabled (worse: the
option was not even present and commented out before I added it a few
months ago), the code is shitty, buggy (eg watch the man page) and not
MP-safe.
Above all, the EtherIP spec (RFC3378) actually recommends dropping
EtherIP and using L2TP instead. We do have L2TP -- written by the
Japanese guys, so it works, it's MP-safe and everything.
Basically people should use L2TP, and I don't see many reasons for
keeping etherip, especially if it's low quality code. Retiring it would
also prune one "unprotected" entry from the TODO.smpnet list.

So what's up? Are we fine? I will remove it soon...
Also, while I'm thinking about it, in terms of broken/unused interfaces
we also have NDIS, which I guess should be marked as "unprotected" in
TODO.smpnet, too.

Does anyone have anything to say about NDIS?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by Maxime Villard

Post by Maxime Villard

Post by m***@m00nbsd.net
We could easily retire etherip. It has never been enabled (worse: the
option was not even present and commented out before I added it a few
months ago), the code is shitty, buggy (eg watch the man page) and not
MP-safe.
Above all, the EtherIP spec (RFC3378) actually recommends dropping
EtherIP and using L2TP instead. We do have L2TP -- written by the
Japanese guys, so it works, it's MP-safe and everything.
Basically people should use L2TP, and I don't see many reasons for
keeping etherip, especially if it's low quality code. Retiring it would
also prune one "unprotected" entry from the TODO.smpnet list.

So what's up? Are we fine? I will remove it soon...
Also, while I'm thinking about it, in terms of broken/unused interfaces
we also have NDIS, which I guess should be marked as "unprotected" in
TODO.smpnet, too.

Does anyone have anything to say about NDIS?

I would delete it.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Post by Christos Zoulas

Post by Maxime Villard

Post by Maxime Villard

Post by m***@m00nbsd.net
We could easily retire etherip. It has never been enabled (worse: the
option was not even present and commented out before I added it a few
months ago), the code is shitty, buggy (eg watch the man page) and not
MP-safe.
Above all, the EtherIP spec (RFC3378) actually recommends dropping
EtherIP and using L2TP instead. We do have L2TP -- written by the
Japanese guys, so it works, it's MP-safe and everything.
Basically people should use L2TP, and I don't see many reasons for
keeping etherip, especially if it's low quality code. Retiring it would
also prune one "unprotected" entry from the TODO.smpnet list.

So what's up? Are we fine? I will remove it soon...
Also, while I'm thinking about it, in terms of broken/unused interfaces
we also have NDIS, which I guess should be marked as "unprotected" in
TODO.smpnet, too.

Does anyone have anything to say about NDIS?

I would delete it.

Yes, let's remove it.

Note that I'm talking about the code in dev/if_ndis and compat/ndis, and that
this doesn't impact urndis, which is a USB driver enabled by default, which
has its own NDIS code.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Brownlee]

On 10 September 2018 at 08:23, Jan Danielsson

Post by Jan Danielsson
[---]

Post by Maxime Villard
Note that I'm talking about the code in dev/if_ndis and compat/ndis, and that
this doesn't impact urndis, which is a USB driver enabled by default, which
has its own NDIS code.

What's the state of urndis? I don't see any "BUGS"-section in the
man-page which I interpret as good news.
I looked at the rndis driver in Linux a few years ago; the developers
seemed pretty displeased with the spec. In summary: "We followed the
spec, it didn't work, so we snooped the line, saw some undocumented
stuff, we tried to add those and suddenly it worked but we don't know
why. Don't use this driver in production.".
Anyone using the urndis driver in NetBSD on a semi-daily basis? Is
it stable?

I use it to tether my Thinkpad via a variety of Android devices. It
had a tendency to panic the system for a while in netbsd-7, but
netbsd-8 has been very stable for me.
I even use it when my iwn occasionally has issues connecting to some
wifi APs - USB tether to android phone, then just connect to the wifi
on the phone.

In short - I don't leave home without it :-p

David

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Tyler Retzlaff]

Post by Christos Zoulas

Post by Maxime Villard
Does anyone have anything to say about NDIS?

I would delete it.

This looks like NDIS 5 and even Microsoft EOL'd certification of drivers
targeting NDIS 5 a very long time ago and it's probably hard to find
devices (let alone the binary drivers).

So +1 for delete

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jan Danielsson]

On 2018-08-25 08:02, Maxime Villard wrote:
[---]

Post by Maxime Villard
Note that I'm talking about the code in dev/if_ndis and compat/ndis, and that
this doesn't impact urndis, which is a USB driver enabled by default, which
has its own NDIS code.

What's the state of urndis? I don't see any "BUGS"-section in the
man-page which I interpret as good news.

I looked at the rndis driver in Linux a few years ago; the developers
seemed pretty displeased with the spec. In summary: "We followed the
spec, it didn't work, so we snooped the line, saw some undocumented
stuff, we tried to add those and suddenly it worked but we don't know
why. Don't use this driver in production.".

Anyone using the urndis driver in NetBSD on a semi-daily basis? Is
it stable?

/Jan

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Should I also bring up sys/netnatm? There was a conversation from Tyler
Retzlaff three years ago [1] (see the mails at the bottom).

There was no objection, and a patch was even about to be committed to
remove netnatm; but apparently Tyler didn't commit it because he was
too busy, and then probably forgot about it.

Basically I agree with what was said in the thread, and I can remove
netnatm (and the associated stuff) now myself.

[1] https://mail-index.netbsd.org/tech-net/2015/05/thread1.html#005117

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Yes, I think I mentioned that netnatm could / should be retired, as well as the Midway ATM driver.

Post by Maxime Villard
Should I also bring up sys/netnatm? There was a conversation from Tyler
Retzlaff three years ago [1] (see the mails at the bottom).
There was no objection, and a patch was even about to be committed to
remove netnatm; but apparently Tyler didn't commit it because he was
too busy, and then probably forgot about it.
Basically I agree with what was said in the thread, and I can remove
netnatm (and the associated stuff) now myself.
[1] https://mail-index.netbsd.org/tech-net/2015/05/thread1.html#005117

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Post by Jason Thorpe
Yes, I think I mentioned that netnatm could / should be retired, as well as
the Midway ATM driver.

I see that now, so let's do it. Someone objecting? It was already discussed
three years ago for the most part.

Removing netnatm implies removing the 'midway' driver, if_atmsubr.c, and
sys/netnatm/; all three are noted as obstacles in TODO.smpnet.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by Maxime Villard

Post by Jason Thorpe
Yes, I think I mentioned that netnatm could / should be retired, as well as
the Midway ATM driver.

I see that now, so let's do it. Someone objecting? It was already discussed
three years ago for the most part.
Removing netnatm implies removing the 'midway' driver, if_atmsubr.c, and
sys/netnatm/; all three are noted as obstacles in TODO.smpnet.

Do it!

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Tyler Retzlaff]

There was mild objection at the time in that the older drivers presented
examples in the variations of hardware that gave us enlightenment in to
how to provide network driver interfaces.

Last I recall someone was going to dig up hardware and test. Without
positive agreement about the removal I didn't proceed with removal.

Post by Maxime Villard

Post by Jason Thorpe
Yes, I think I mentioned that netnatm could / should be retired, as well as
the Midway ATM driver.

I see that now, so let's do it. Someone objecting? It was already discussed
three years ago for the most part.
Removing netnatm implies removing the 'midway' driver, if_atmsubr.c, and
sys/netnatm/; all three are noted as obstacles in TODO.smpnet.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

I would also like to remove these two includes:

netinet6/ipsec.h
netkey/keysock.h

None of the other BSDs has these obsolete includes, and I find them
misleading.

They are leftovers from the KAME ipsec, which we removed a while ago. The
ipsec includes are basically highly OS-specific, and are not used in the
wild. They are only used by ipsec-tools, which has already been fixed to
use the proper includes.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Post by Maxime Villard
netinet6/ipsec.h
netkey/keysock.h
None of the other BSDs has these obsolete includes, and I find them
misleading.

No objections here.

Post by Maxime Villard
They are leftovers from the KAME ipsec, which we removed a while ago. The
ipsec includes are basically highly OS-specific, and are not used in the
wild. They are only used by ipsec-tools, which has already been fixed to
use the proper includes.

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

There was mild objection at the time in that the older drivers presented examples in the variations of hardware that gave us enlightenment in to how to provide network driver interfaces.

There's always the Attic...

Last I recall someone was going to dig up hardware and test. Without positive agreement about the removal I didn't proceed with removal.

At some point, though, someone has do do more than agree to "dig up hardware and test". If the code needs a major overhaul in order for the system as a whole to make progress and no one is willing to do that, well...

Post by Maxime Villard

Post by Jason Thorpe
Yes, I think I mentioned that netnatm could / should be retired, as well as
the Midway ATM driver.

I see that now, so let's do it. Someone objecting? It was already discussed
three years ago for the most part.
Removing netnatm implies removing the 'midway' driver, if_atmsubr.c, and
sys/netnatm/; all three are noted as obstacles in TODO.smpnet.

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Post by Jason Thorpe

Post by Ryota Ozaki
Removing a component, even if it's small, is still useful for developers of
networking stuffs. We're sometimes annoyed by old, unmaintained codes
when we need to touch every network components because such codes
are often written in old fashion and difficult to touch (one noticeable
example is sys/dev/pci/if_lmc.c). Also if we want to turn NET_MPSAFE
on by default, all network components have to be taken care, so reducing
the number of components just makes the goal close.

Yes, that's exactly my point. There is a ton of dead wood in there that
just needs to go. if_lmc.c is another perfect example.

I would vote for removing lmc.

Post by Jason Thorpe
- The Midway ATM driver and the associated netnatm stack.
- The RoadRunner HIPPI driver and associated if_hippisubr (even though that
one is near and dear to my heart).
- We still have Matt Thomas's original "de" Tulip driver, which was long
ago supplanted by if_tlp.c (which supports more device flavors and more
bus attachments)

Then why do we keep "de" exactly? Since there is already a replacement.

Post by Jason Thorpe
- There are some ISA Ethernet drivers that don't support even basic
features required by modern network protocols (e.g. the "eg" driver that
doesn't support multicast, for example).

I'm a bit confused here. I don't see any kern conf that has "eg". Unless I'm
missing something, it looks like dead code that has never been enabled.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

On Sep 13, 5:12pm, Maxime Villard wrote:
} Re-reading Jason's email:
} > > On Jul 12, 2018, at 6:39 PM, Ryota Ozaki <ozaki-r%***@localhost> wrote:
} > > Removing a component, even if it's small, is still useful for developers of
} > > networking stuffs. We're sometimes annoyed by old, unmaintained codes
} > > when we need to touch every network components because such codes
} > > are often written in old fashion and difficult to touch (one noticeable
} > > example is sys/dev/pci/if_lmc.c). Also if we want to turn NET_MPSAFE
} > > on by default, all network components have to be taken care, so reducing
} > > the number of components just makes the goal close.
} >
} > Yes, that's exactly my point. There is a ton of dead wood in there that
} > just needs to go. if_lmc.c is another perfect example.
}
} I would vote for removing lmc.
}
} > Other examples off the top of my head:
} >
} > - The Midway ATM driver and the associated netnatm stack.
} > - The RoadRunner HIPPI driver and associated if_hippisubr (even though that
} > one is near and dear to my heart).
} > - We still have Matt Thomas's original "de" Tulip driver, which was long
} > ago supplanted by if_tlp.c (which supports more device flavors and more
} > bus attachments)
}
} Then why do we keep "de" exactly? Since there is already a replacement.
}
} > - There are some ISA Ethernet drivers that don't support even basic
} > features required by modern network protocols (e.g. the "eg" driver that
} > doesn't support multicast, for example).
}
} I'm a bit confused here. I don't see any kern conf that has "eg". Unless I'm
} missing something, it looks like dead code that has never been enabled.

You didn't look very hard. Check i386/conf/GENERIC (and
various others). You'll find most ISA drivers there.

}-- End of excerpt from Maxime Villard

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Post by Maxime Villard

Post by Jason Thorpe
- There are some ISA Ethernet drivers that don't support even basic
features required by modern network protocols (e.g. the "eg" driver that
doesn't support multicast, for example).

I'm a bit confused here. I don't see any kern conf that has "eg". Unless I'm
missing something, it looks like dead code that has never been enabled.

Forget about it, I was being dumb; it is enabled as "eg0" in i386/amd64, and
not as "eg*".

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by Maxime Villard
Then why do we keep "de" exactly? Since there is already a replacement.

Neither de nor tlp work with all Tulip chips/configurations.

Post by Maxime Villard
I'm a bit confused here. I don't see any kern conf that has "eg". Unless I'm
missing something, it looks like dead code that has never been enabled.

i386/conf/GENERIC
i386/conf/GENERIC2
i386/conf/GENERIC2_TINY
i386/conf/INSTALL_FLOPPY

[Maxime Villard]

Post by Michael van Elst

Post by Maxime Villard
Then why do we keep "de" exactly? Since there is already a replacement.

Neither de nor tlp work with all Tulip chips/configurations.

If you mean that the latter is not a complete replacement of the former, then
that's fine.

The reason I insist on this thread is because I don't want us to keep dead
stuff if we already know they are unused/broken. So I'm scanning ancient
discussions, and also this one, to see what we can remove. Dead stuff needs
to be retired.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Does someone know what is the state of netisdn? It is a big chunk of
apparently dead code. FreeBSD removed it more than ten years ago [1] because
it was already dead back then, and also not MP-safe.

The reason I'm bringing this up is because while grepping through the tree I
landed in iavc(4), iavc_send(), which has a big memory corruption: we free
the m->m_next chain twice. Digging more, I see two PRs about iavc that seem
to indicate it does not compile on 64bit (are they outdated? because iavc* is
in amd64-ALL).

Looking at netisdn, it seems rather clear that it is of very poor quality,
and there is a lot of dead code hanging around. For example there is daic(4),
which is commented out in conf/files, so basically it never builds anywhere.
Its man page, which dates back to 1998, even says "The driver is not yet
finished".

netisdn is marked as an unprotected component in our TODO.smpnet. While it was
maybe fun at a time to keep dead drivers like that, we now have good reasons
to retire them, the first one being MP-safety. What do people think about
that?

[1] https://reviews.freebsd.org/rS179315

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Maxime Villard
Does someone know what is the state of netisdn? It is a big chunk of
apparently dead code.

I used it heavily in the past, and still have lots of hardware, but no
setup to test anything easily.

No objection to the removal from me.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by Maxime Villard
Does someone know what is the state of netisdn? It is a big chunk of
apparently dead code. FreeBSD removed it more than ten years ago [1] because
it was already dead back then, and also not MP-safe.
The reason I'm bringing this up is because while grepping through the tree I
landed in iavc(4), iavc_send(), which has a big memory corruption: we free
the m->m_next chain twice. Digging more, I see two PRs about iavc that seem
to indicate it does not compile on 64bit (are they outdated? because iavc* is
in amd64-ALL).
Looking at netisdn, it seems rather clear that it is of very poor quality,
and there is a lot of dead code hanging around. For example there is daic(4),
which is commented out in conf/files, so basically it never builds anywhere.
Its man page, which dates back to 1998, even says "The driver is not yet
finished".
netisdn is marked as an unprotected component in our TODO.smpnet. While it was
maybe fun at a time to keep dead drivers like that, we now have good reasons
to retire them, the first one being MP-safety. What do people think about
that?

I doubt that anyones is using it; I would vote to delete it.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Post by Christos Zoulas

Post by Maxime Villard
Does someone know what is the state of netisdn? It is a big chunk of
apparently dead code. FreeBSD removed it more than ten years ago [1] because
it was already dead back then, and also not MP-safe.
The reason I'm bringing this up is because while grepping through the tree I
landed in iavc(4), iavc_send(), which has a big memory corruption: we free
the m->m_next chain twice. Digging more, I see two PRs about iavc that seem
to indicate it does not compile on 64bit (are they outdated? because iavc* is
in amd64-ALL).
Looking at netisdn, it seems rather clear that it is of very poor quality,
and there is a lot of dead code hanging around. For example there is daic(4),
which is commented out in conf/files, so basically it never builds anywhere.
Its man page, which dates back to 1998, even says "The driver is not yet
finished".
netisdn is marked as an unprotected component in our TODO.smpnet. While it was
maybe fun at a time to keep dead drivers like that, we now have good reasons
to retire them, the first one being MP-safety. What do people think about
that?

I doubt that anyones is using it; I would vote to delete it.

To be clear on what it covers: this implies removing the aivc and isic
drivers. I will proceed with the former now (see above), and with the rest
soon...

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Post by Maxime Villard

Post by Christos Zoulas

Post by Maxime Villard
Does someone know what is the state of netisdn? It is a big chunk of
apparently dead code. FreeBSD removed it more than ten years ago [1] because
it was already dead back then, and also not MP-safe.
The reason I'm bringing this up is because while grepping through the tree I
landed in iavc(4), iavc_send(), which has a big memory corruption: we free
the m->m_next chain twice. Digging more, I see two PRs about iavc that seem
to indicate it does not compile on 64bit (are they outdated? because iavc* is
in amd64-ALL).
Looking at netisdn, it seems rather clear that it is of very poor quality,
and there is a lot of dead code hanging around. For example there is daic(4),
which is commented out in conf/files, so basically it never builds anywhere.
Its man page, which dates back to 1998, even says "The driver is not yet
finished".
netisdn is marked as an unprotected component in our TODO.smpnet. While it was
maybe fun at a time to keep dead drivers like that, we now have good reasons
to retire them, the first one being MP-safety. What do people think about
that?

I doubt that anyones is using it; I would vote to delete it.

To be clear on what it covers: this implies removing the aivc and isic
drivers. I will proceed with the former now (see above), and with the rest
soon...

A more exhaustive list of drivers: iavc, isic, ifpci, ifritz, iwic.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Maybe we should do better filtering when adding stuff. For example, SCTP
should not have been added, there is an enormous work to do to make it
~reasonable, and it doesn't look like anyone has any intention to do that
any time soon.

So it's here, with its thousands of lines of code, it consumes APIs and
makes stuff harder to change; but it will never be enabled.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Maxime Villard
Maybe we should do better filtering when adding stuff. For example, SCTP
should not have been added, there is an enormous work to do to make it
~reasonable, and it doesn't look like anyone has any intention to do that
any time soon.
So it's here, with its thousands of lines of code, it consumes APIs and
makes stuff harder to change; but it will never be enabled.

Maxime, it is very good that you are enthusiastic, but your "it needs
to be perfect" attitude and the way you shoot around and hurt people
does IMHO actively discurage people from improving NetBSD.

Please use technical criticisms if you have any, but avoid this broad
"everything is shit" mails. Everyone will read an implied "unless I did it"
and dismiss your (probably valid) point (that you did not even make).

Sorry to be blunt,

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Post by Martin Husemann

Post by Maxime Villard
Maybe we should do better filtering when adding stuff. For example, SCTP
should not have been added, there is an enormous work to do to make it
~reasonable, and it doesn't look like anyone has any intention to do that
any time soon.
So it's here, with its thousands of lines of code, it consumes APIs and
makes stuff harder to change; but it will never be enabled.

Maxime, it is very good that you are enthusiastic, but your "it needs
to be perfect" attitude and the way you shoot around and hurt people
does IMHO actively discurage people from improving NetBSD.
Please use technical criticisms if you have any, but avoid this broad
"everything is shit" mails. Everyone will read an implied "unless I did it"
and dismiss your (probably valid) point (that you did not even make).

I didn't even give technical criticism because it's exactly the same thing
as racoon. Except that this is kernel code - that is thankfully disabled by
default.

So watch the packet entry point, sctp_input(), full of dead stuff already,
there is even a printf (really?), half of what is being done is wrong like
changing 'iphlen', the IPsec stuff is not implemented correctly, and so on.

Then the code in general, which is uselessly big and messy (see the number
of arguments given to each function for example), that probably makes wrong
use of the mbuf API (like M_PROTO1), is invasive, and doesn't look far from
collapsing completely. As a side note, I am also personally aware of a
buffer overflow deep in the SCTP packet handling.

Not to mention that the commit message for all of that code did not even
say where the code was coming from.

I'm not saying that we should remove SCTP, but rather that it probably
shouldn't have been imported in the first place. In its current state it
is obvious we won't enable it anytime soon, and it doesn't look like
anyone is working on improving that state.

The interest of SCTP is also highly questionable, given that it has a very
limited use. There is no demand for that, and Windows/MacOS don't implement
it.

But if you ask me, worst of all, it looks like if I'm not here to question
stuff, no one else will. So yes, here come my mails about ipf, racoon, natm,
ndis, etc, sctp, all written the same way, because it's always the same
problem. It is better to question now, rather than letting things spiral
down into problems we have no idea how to fix correctly.

That SCTP, too, is in a bad state, is not an insult to whoever imported
it, it's just a fact, and a problem. Perhaps we wouldn't be having this
kind of problem if we did more filtering on what we decide to import. But
maybe someone can contradict me?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

I believe we can retire if_lmc? It was already mentioned some time ago
by Ryota [1], in addition to being in TODO.smpnet. I agree with his
assessment, and I propose to retire it.

[1] http://mail-index.netbsd.org/tech-net/2018/07/13/msg006971.html

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Post by Maxime Villard
I believe we can retire if_lmc? It was already mentioned some time ago
by Ryota [1], in addition to being in TODO.smpnet. I agree with his
assessment, and I propose to retire it.
[1] http://mail-index.netbsd.org/tech-net/2018/07/13/msg006971.html

No objections from me, of course. But I also like the idea that someone on that thread proposed about some sort of "retired driver reference" README in case anyone finds hardware and wants to resurrect a retired driver (and rewrite it to modern standards as a part of doing so).

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ryota Ozaki]

Post by Maxime Villard
I believe we can retire if_lmc? It was already mentioned some time ago
by Ryota [1], in addition to being in TODO.smpnet. I agree with his
assessment, and I propose to retire it.
[1] http://mail-index.netbsd.org/tech-net/2018/07/13/msg006971.html

+1, of course. The driver has not received even love of KNF :-/

ozaki-r

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Post by Ryota Ozaki

Post by Maxime Villard
I believe we can retire if_lmc? It was already mentioned some time ago
by Ryota [1], in addition to being in TODO.smpnet. I agree with his
assessment, and I propose to retire it.
[1] http://mail-index.netbsd.org/tech-net/2018/07/13/msg006971.html

+1, of course. The driver has not received even love of KNF :-/
ozaki-r

So, I will remove it soon. Note that this includes the lmcconfig tool.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Phil Nelson]

Post by Maxime Villard
Not really related to networking, but I just saw PR #21345, and there
seem to be more dead drivers that need to go. As Jason pointed out,
"satlink" is one of them; it has no man page, is not enabled anywhere
except ALL, and has no use either.

I actually used the satlink driver in Fall of 2017 ... I was teaching a class on
drivers and for NetBSD I used satlink has been a simple example of a driver
that has been my starting example of how to do a NetBSD driver. The
students know it is old, but it does give them a great introduction.

I do point them to more complicated code later.

Any candidate drivers that are nearly as simple as satlink? I'm sure I'll
be asked to teach our "device drivers" class in the future some time.

--Phil

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by Maxime Villard
Not really related to networking, but I just saw PR #21345, and there
seem to be more dead drivers that need to go. As Jason pointed out,
"satlink" is one of them; it has no man page, is not enabled anywhere
except ALL, and has no use either.

Remove it...

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Post by Christos Zoulas

Post by Maxime Villard
Not really related to networking, but I just saw PR #21345, and there
seem to be more dead drivers that need to go. As Jason pointed out,
"satlink" is one of them; it has no man page, is not enabled anywhere
except ALL, and has no use either.

Remove it...
christos

Yes, will remove...

Regarding the examples, just take mm.c, it's as simple as satlink. By
the way, looking at mm.c, there seems to be some dead code under
#ifdef pmax.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Not really related to networking, but I just saw PR #21345, and there
seem to be more dead drivers that need to go. As Jason pointed out,
"satlink" is one of them; it has no man page, is not enabled anywhere
except ALL, and has no use either.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de