... 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. On 01.08.2018 17:51, triaxx wrote: > 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 <ozaki-r%netbsd.org@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. >> >> 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
Attachment:
signature.asc
Description: OpenPGP digital signature