ctau, cx committed in rS258554; no need for debate or lengthy process for old ISA cards.
leave this review for ce, cp
emaste on Mar 2 2020, 5:34 PM.Authored by
Why are we dropping these (other than cx?)
Has firstname.lastname@example.org been contacted on this? I see that these cards can still be purchased, even the ancient ISA card, though I have no issue dropping that since we dropped ISA (cx driver).
These drivers contain obfuscated source which is what prompted me to look at them, and when I started looking I can find no evidence of anyone using them. There is a cost in keeping them; for 10+ years they've had many changes required as other things happen in the tree.
I suspect there's no conflict over cx and I should add the notice for it and remove it imminently?
I called Cronyx and here is information I got. All the devices from http://cronyx.ru/hardware/wan.html can be ordered and purchased, even the ISA ones. The FreeBSD drivers were discontinued back when rik@ quit them, and couple years later the Linux drivers were discontinued, too. Right now there are no driver developers at Cronyx at all. However, they got small but constant demand for all of the devices they produce. They can't disclose who buys them and what OS do they run. The tech support guy was responsive and nice to talk to. We discussed a hypothetical situation when someone buys for example Tau-PCI, runs FreeBSD and encounters a problem. If I would offer my help to this user, would Cronyx offer their help to me? The guy on the other side of the phone repeated that they don't have driver developers now, but they would be able to provide some information on hardware to a FreeBSD person who is maintaining the drivers.
So, my vote would be to keep the PCI drivers as long as they aren't a big burden to be kept in a compilable state. If maintaining sppp becomes a PITA, I'm pretty sure that we can ignore top parts of the drivers, and leave only the part that actually works with hardware and frames data to NETGRAPH. Basically compile in the NETGRAPH mode only, effectively nuking sppp support. You can assign me as a maintainer(ish).
spl calls is not something that gives any maintenance burden. They have been defined to nop for years. Of course it makes sense to cleanup those that aren't mentioned anywhere just like rS364918 did. However, I don't think just removing these nop defines is a holy grail we should aim for.
No, but they do give an indication of drivers/code that has not been reviewed or maintained for some time. There are some left in drivers that are clearly still important (e.g. atkbd), but in any case for all spl* calls we should eventually take one of three paths: