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

> 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?

Correct.
It's all about HFC based cards/dongles.

> I definitely hate breaking existing setups, but if the only remaining
> use case for i4l/hisax is the call divert feature, that doesn't

The only use case you know of so far.
I'm not sure if some old fashioned mailing list gives a sensible
representation of what's going on out there.
If I had not read back in the time that this is the place to post patches, I
wouldn't be here, either.

> feel like enough of a reason to keep a two megabytes of source code
> around for it.

You could shrink it by removing the protocol decoder, just like I did.
I never felt that the kernel space was the right place for that part.

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

As I understand, at least part of that work has been done.
Unfortunately I didn't succeed in contacting him about it.

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

That would be really bad for maintenance. Just like having that extra git for
mISDN.
It means that, what's essentially a single patch, has to be split across two
or then even three different reopsitories. That even introduces some ugly
dependencies.
We just had a session about the hurdles of participating in FOSS projects at
our Barcamp yesterday. That would be exactely such a thing. (or even multiple
ones)
But I surely need to get back to square on that as well and get the formal
things right.

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

Doesn't sound too bad to me.
But as I moted a few weeks back there is a rather annoying bug in mISDN
apart from that dreaded usage counter thing.
So even if I4L may not be suited well for modern voice plattforms it's
surely the most stable, we had so far.

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

For most users maybe. Technically for a small part.
AFAIK LCR is the only application natively using mISDN.

I remember an Asterisk channel was mentioned once. I'm not sure if that was
by Karsten as well. But that was never released, either.
That's why some Asterisk users even still rely on the "old and deprecated"
mISDN version, not the current one.
So as far as (the socket based) mISDN replacing it's predecessors goes, we
might be waiting forever :-(

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

Neither do I, But I do feel that keeping things together would be essetial
to being able to maintain things.
The situation is unfortunately already pretty messy and I feel like it might
become even worse. with pieces being scattered around even more places.

I also find the discussion somewhat arduous. It'd rather spend the time to get
the technical issues fixed.

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

Interesting interpretation.

> 5.2, then you are still stuck with the same problem but we have
> extra work maintaining it for another year.

Maybe you could explain to us what the exact problem is?
What sort of work needs to be done to keep things working?

> > 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 hardware I'm currently evaluating does show some stange behaviour that
according to my research is because the Apollo Lake architecture requires a
later kernel. Which is what I would have been working on now if it wasn't
for some other things going pear shaped.

> 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

Not really an issue. You can even still get boards with ISA slots if you need
them. Or stand alone PCI-e to PCI bridges.
But you can also get HFC based PCI-e cards. So either way that was a rather
unfitting comment. There is no need for old mainboards.

  Greetings,
    WIMPy