Add deprecation notices to ce and cp sync serial drivers

[emaste]

Summary

ctau, cx committed in rS258554; no need for debate or lengthy process for old ISA cards.

leave this review for ce, cp

[emaste]

correct gone_in_dev usage

[rgrimes]

Why are we dropping these (other than cx?)

Has [e-mail] 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).

[emaste]

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?

[emaste]

ctau is also ISA, and discontinued by Cronyx, with no support from them for FreeBSD 7+
http://www.cronyx.ru/hardware/tau.html

[glebius]

These cards seem to be still produced and sold http://cronyx.ru/hardware/wan.html

I'm pretty sure Roman doesn't work there since 2010. I will try to talk to Cronyx to clarify current status.

[emaste]

Thanks for checking with Cronyx @glebius.

I suspect that supporting PCI hardware is borderline but you can still get specialty mainboards with PCI slots when I last looked. Is T1/E1 still relevant though?

[trasz]

Perhaps also add the notice to the sconfig(8) man page?

[emaste]

Did you hear back from Cronyx?

[emaste]

• add mn
• add sconfig

[glebius]

Sorry, totally forgot about this. Will call them today/tomorrow.

[emaste]

@glebius were you able to find out anything?

[emaste]

Some time ago I started a thread on FreeBSD-stable to ask if there are any users and received no responses.

[imp]

I think enough time has passed.

sbin/sconfig/sconfig.8

14

It's been long enough the date should change :)

[phk]

I have seen neither a V.35 nor E1/T1 line outside datamuseum.dk in the last decade.

[emaste]

@glebius have you heard back from Cronyx?

[glebius]

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).

[emaste]

Prompted by rS364918 @imp and I took a look at remaining spl* use, and ce and cp came up as still having spl calls. I think it's sensible to put in a deprecation notice, and see if anyone shows up to review/update the drivers.

[glebius]

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.

[emaste]

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:

1. Remove the nop spl calls if the driver has already been appropriately modified
2. Review and add locking where necessary, then remove the spl calls
3. Retire the unmaintained/unused code

[emaste]

mn(4) removed in 0cff00ae682a032dec29494f88c76d78a08edfa1

[emaste]

PR264160: likely heap overflow in driver for Cronyx [ce(4), cp(4)] adapters (others also possibly affected)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264160