[2/2] isdn: i4l: move active-isdn drivers to staging

Am 04.03.2016 um 17:18 schrieb Paul Bolle:
> [Added Tilman and Christoph.]
> 
> On vr, 2016-03-04 at 16:24 +0100, Arnd Bergmann wrote:
>> I actually did more patches that I ended up not submitting:
>>
>> * move hisax to staging
>> * remove i4l support from gigaset
> 
> For the record: I have no reason to object a patch that does that. (I'm
> not aware anyone complained when gigaset switched its default from i4l
> to capi. By now all relevant distributions should use our capi driver.)

No objection from me either. When the Gigaset driver is built for CAPI
it can still be used from i4l applications via capidrv with no loss of
functionality. That was a primary goal of the CAPI port.

>> * move i4l core to staging

That's a different story. Removing i4l support will actually remove a
userspace visible feature.

> On a local tree I have two (draft) patches that do some related
> preliminary work:
> - isdnhdlc: move into separate directory
> - mISDN: NETJet: stop selecting ISDN_I4L
> 
> These trivial patches untangle mISDN and i4l.

That would be a good thing regardless of any decision on the future of
the i4l userspace interface.

> For my part I'm surprised that anyone is still using it. But apparently
> the hardware that required commit 19cebbcb04c8 and 3460baa62068  (which
> I'm unfamiliar with) is still operational. And since there never has
> been, as far as I know, a global i4l to capi migration nor a global i4l
> (and capi) to mISDN migration it might be that some people are stuck on
> i4l drivers for their hardware. Perhaps that explains Cristoph's
> commits.

The trouble is that mISDN never cared about migration or backward
compatibility. So while users of i4l applications have no problem with
i4l drivers being ported to CAPI and dropping native i4l support, they
do have a problem with drivers making that move to mISDN.

That is the situation of the hisax driver today. mISDN started as a
project to migrate hisax to CAPI but regrettably dropped that goal in
favor of a newly invented API leaving old i4l based applications behind.
As a consequence, owners of HiSAX type adapters are in fact stuck with
the old hisax driver if they want to continue using i4l userspace tools.

In my opinion, i4l, capidrv and hisax need to stay in the supported part
for the time being as they are still actively used. Native i4l support
can and should be dropped for hardware with CAPI drivers (ie. gigaset)
but not for hardware with only mISDN drivers (ie. hisax). And finally,
ISDN_CAPI_CAPIDRV should be enabled automatically if both ISDN_I4L and
ISDN_CAPI are enabled, ie. something like:



Jm2c,
Tilman

On za, 2016-03-05 at 14:08 +0100, Tilman Schmidt wrote:
> As a consequence, owners of HiSAX type adapters are in fact stuck with
> the old hisax driver if they want to continue using i4l userspace
> tools.

Do you know whether or not mISDN tools offer functionality comparable to
i4l tools?


Paul Bolle

Am 07.03.2016 um 09:48 schrieb Paul Bolle:
> On za, 2016-03-05 at 14:08 +0100, Tilman Schmidt wrote:
>> As a consequence, owners of HiSAX type adapters are in fact stuck with
>> the old hisax driver if they want to continue using i4l userspace
>> tools.
> 
> Do you know whether or not mISDN tools offer functionality comparable to
> i4l tools?

AFAICS they don't. mISDN seems very much geared towards voice use, for
example with Asterisk. The entire topic of ISDN data connections appears
to be missing. I don't see how someone currently using i4l for Internet
dial-in (either client or server side) could migrate to mISDN.

Am 09.03.2016 um 23:10 schrieb Tilman Schmidt:
> Am 07.03.2016 um 09:48 schrieb Paul Bolle:
>> On za, 2016-03-05 at 14:08 +0100, Tilman Schmidt wrote:
>>> As a consequence, owners of HiSAX type adapters are in fact stuck with
>>> the old hisax driver if they want to continue using i4l userspace
>>> tools.
>>
>> Do you know whether or not mISDN tools offer functionality comparable to
>> i4l tools?
> 
> AFAICS they don't. mISDN seems very much geared towards voice use, for
> example with Asterisk. The entire topic of ISDN data connections appears
> to be missing. I don't see how someone currently using i4l for Internet
> dial-in (either client or server side) could migrate to mISDN.
> 

Not true.
mISDN with CAPI support works just fine with pppd and pppdcapiplugin and
the CAPI works for all mISDN HW.

Following I4L services are not supported:

- RAW IP dialin/dialout
- termnal connections via X75 (e.g. dialin via minicom on a remote machine).
- isdndivert

RAW IP was very popular in the nineties because of easy to setup and low
protocol overhead, but very insecure, since only authorization was done
by the phone numbers. This was not a such big issue in the nineties,
since it was hard to get a public line with the allowance to send any
numbers.
Today this is no problem to get the allowance (if you can get a new ISDN
line at all - which is more a problem today).
Terminal connection where only used seldom, more as last resort or for
debuging.
isdndivert was used to manage call redirections, it could be easely
replaced by an mISDN or CAPI application, but here were not so much
requests for it. Since Telekom offers callredirection in their Web
customer center here is no much need anyways.


Karsten

Hi Karsten,

On do, 2016-03-10 at 11:53 +0100, isdn@linux-pingi.de wrote:
> mISDN with CAPI support works just fine with pppd and pppdcapiplugin
> and the CAPI works for all mISDN HW.

In the mainline tree the mISDN and CAPI stacks are effectively separate.
Do you perhaps refer to a mISDN + Asterisk + chan-capi setup? (That's
the closest to mISDN with CAPI support that I could find. Did I miss
something?)

Thanks,


Paul Bolle

Am 10.03.2016 um 13:58 schrieb Paul Bolle:
> Hi Karsten,
> 
> On do, 2016-03-10 at 11:53 +0100, isdn@linux-pingi.de wrote:
>> mISDN with CAPI support works just fine with pppd and pppdcapiplugin
>> and the CAPI works for all mISDN HW.
> 
> In the mainline tree the mISDN and CAPI stacks are effectively separate.
> Do you perhaps refer to a mISDN + Asterisk + chan-capi setup? (That's
> the closest to mISDN with CAPI support that I could find. Did I miss
> something?)

http://listserv.isdn4linux.de/pipermail/isdn4linux/2012-January/005580.html

Since 2012 mISDN has a cAPI20 interface, pure in userspace.
Everything is in the capi20 subdirectory of mISDNuser.
The capi20 support need to be enabled with ./configure.

Has nothing to do with Asterisk, but for FAX it is useing the same DSP
library, spandsp.

Best
Karsten Keil

Am 10.03.2016 um 17:41 schrieb isdn@linux-pingi.de:
> Am 10.03.2016 um 13:58 schrieb Paul Bolle:
>> On do, 2016-03-10 at 11:53 +0100, isdn@linux-pingi.de wrote:
>>> mISDN with CAPI support works just fine with pppd and pppdcapiplugin
>>> and the CAPI works for all mISDN HW.
>>
>> In the mainline tree the mISDN and CAPI stacks are effectively separate.

Correct.

> Since 2012 mISDN has a cAPI20 interface, pure in userspace.

To expand: The documented interface for CAPI 2.0 applications is the
shared library libcapi20.so. Originally that library just interfaced to
the kernel CAPI subsystem through /dev/capi20. Later it was extended to
support different access paths to ISDN devices:
- via /dev/capi20 and kernel CAPI as before
- over the network and a remote CAPI server running rcapid
- over the network to FRITZ!Box router via AVM's CAPI-over-TCP service
- last but not least, via the mISDNcapid daemon and mISDN

Of course this cuts off anything that doesn't pass through libcapi20.so,
including applications that (against the standard) access /dev/capi20
directly but also the capidrv.ko i4l compatibility shim.