tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Time to retire some ancient network pseudo-interfaces?

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"

Le 2018-07-13 06:17, Jason Thorpe a écrit :
On Jul 12, 2018, at 6:39 PM, Ryota Ozaki <> 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.

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

Home | Main Index | Thread Index | Old Index