Re: [PATCH 0/5] isdn: deprecate non-mISDN drivers

On Fri, Apr 26, 2019 at 12:39 AM Birger Harzenetter <[email protected]> wrote:

> > Can you point to a specific installation that uses those obsolete drivers
> > on modern kernels? Generally I would assume that any installation
> > that is conservative enough to still rely on those drivers would have
> > long ago stopped upgrading major kernel versions.
>
> I have it installed on all our voice application servers for the reason of
> being able to use divertctrl even if they are running mISDN in normal
> operation. It's more than ugly, but better than nothing at all.
> The machines are currently running 4.9, but I need to upgrade to be able
> to use currently available mainboards.

Ok, so if you are using both mISDN and i4l, then I assume you have
"hisax" compatible passive hardware using i4l, not any of the CAPI supported
drivers (avmb1, hysdn, gigaset, cmtp), right?

I definitely hate breaking existing setups, but if the only remaining
use case for i4l/hisax is the call divert feature, that doesn't
feel like enough of a reason to keep a two megabytes of source code
around for it.

Karsten has previously noted that he did not think diversion was an
important feature to have in mISDN, but I guess it would not be that
hard to implement if there is a strong use case after all.

I can also offer help with creating an external module version of
drivers/isdn/{i4l,hisax} that retains the git history and makes it possible
to compile outside of mainline Linux. Since many users already use
an out-of-tree mISDN, I hope that would reduce the impact of
removing it.

I'm not offering to maintain that tree long-term, but for the most part
the drivers are fairly independent of the kernel versions and rarely
need to change: most of the patches to drivers/isdn/ appear to
be based on bugs that are found by code inspection rather than
the necessity to change it.

> > The last time that anyone seems to have actually done any isdn4linux
> > development appears to be in 2012 when Jiri Slaby sent a series of
> > cleanups for the the tty code, but it's not entirely clear if he tested it.
>
> I have to admit I haven't done any extensive testing, but I certainly din't
> notice any bugs.
> I know it may seem unimaginable in our modern times, but did it ever occour
> to you that maybe it isn't being changed because it just works as intended?

I have read the sources and fixed several bugs myself. The isdn4linux code
base was in need of a rewrite 15 years ago when linux-2.6 was released
that never happened (other than mISDN replacing it for the most part).

> Thare had been a suggestion at our hackerspace to set up some BBS systems so
> that people could experience how things worked in the old days.
> Maybe I should take up on that idea and add some ipppd dial-in to that.
> Even if it's just to confirm that it actually still works.

That sounds like a fun project, but it doesn't require doing that on
future kernels. In fact it sounds like just as much fun to do it with
linux-2.4 ;-)

> > There is exactly one version of mISDN in the mainline kernel. Any other
> > version is meaningless to this discussion.
>
> If it's about things being maintained or not, I see that as quite important.
> Maybe the issue is not that tings are not being maintained, but rather that
> the efforts don't make it upstream for whatever reason outside the scope
> of this discussion?

The fork of mISDN not making it back into mainline is a problem,
but it's completely orthogonal to the question of how to deal with
the other two ISDN stacks, unless you suggest removing the in-kernel
version of the mISDN stack as well. I wasn't trying to suggest that here.

> > How much longer do you expect to need it?
>
> At least as long as the ISDN is running and being used.
> And I expect that to be quite some more years.

Ok, I take that as a vote in favor of removing it now rather than
delaying the inevitable. If we remove i4l in 5.7 rather than
5.2, then you are still stuck with the same problem but we have
extra work maintaining it for another year.

> > SLES15 and RHEL8 will have
> > 4.x kernels for many years to come, and even Ubuntu 18.04 will still
> > get updates until 2023.
>
> But you won't get support for current hardware then.

Usually PC style hardware is fairly good about staying compatible
with old operating systems, as long as you don't rely on new
hardware features.

The other thing you don't get with modern mainboards is PCI slots
(especially more than one), so you may need to start stocking up on
those. That would also solve the problem of staying on a kernel with
i4l support. See
https://www.idealo.de/preisvergleich/ProductCategory/3018F108295-108297-259124-9050631-9855068.html

     Arnd