New ISDN driver

[Hans Petter Selasky]

On Sunday 14 August 2005 10:27, Michael Reifenberger wrote:
> On Fri, 12 Aug 2005, Hans Petter Selasky wrote:
> > Date: Fri, 12 Aug 2005 18:16:49 +0200
> > From: Hans Petter Selasky <hselasky at c2i.net>
> > To: freebsd-isdn at freebsd.org, hellmuth.michaelis at t-online.de
> > Subject: Re: New ISDN driver
> >
> > On Friday 12 August 2005 16:36, Hellmuth Michaelis wrote:
> >> Michael Reifenberger wrote:
> >>> So now we have stock I4B, your I4B and C4B.
> >>>
> >>> Has there been any effords to merge the whole lot (at least) into
> >>> -current?
> >>
> >> With regards to Hans Petters ISDN driver:
> >>
> >> There are for shure some parts of Hans Petters driver which fix bugs
> >> and/or enhance i4b and therefore should be integrated into i4b.
>
> If one compares the current I4B and yours:
> - Is the new one running GIANT free?

Yes, everything. Currently there is one lock per i4b controller, and I don't 
think it makes sense to have finer granularity than that.


> - Does it support all current drivers or are some missing?


I found out that NetBSD has some more ISDN drivers than FreeBSD, but if we are 
speaking about FreeBSD, everything has been brought into my new system, 
except what you find in /sys/i4b/layer1/ifpi2 and /sys/i4b/layer1/capi . I 
plan to port the ifpi2 driver when I have got some time, but I think that one 
will be better off buying a new HFC-S PCIA ISDN card or some of the supported 
USB adapters.

> - Is NETGRAPH (i4bing) supported/testet (just necessary for me)?

i4bing does currently not compile on FreeBSD-7, but it might compile on 
FreeBSD 5.4, and I will fix that, hence the Netgraph system has been updated, 
since I last checked. But the file is there and if you do a one by one line 
comparison with the official version, is should not take very long to update 
it and get it compiling again. But if you just want to set up an IP link, 
"i4bipr" and "i4bsppp" has been fully tested, and confirmed to work.

> - Is your CAPI implementation integratable with C4B?

Thomas and I conform to the same CAPI standard, so by putting a layer on top 
of I4B and C4B, that switches messages by controller, it should be possible 
to use both systems at the same time. The problem is only that the users will 
be confused by all the different controller numbers. So actually it would be 
very nice if C4B could allocate an "i4b controller" and use that controller 
number. Here I am referring to my version of I4B. Another thing is the 
"capi20.h" header files. They are completely different, and maybe someone 
wants to review which is better, because we cannot have a CAPI system with 
two "capi20.h" header files.

From what I understand Thomas is not interrested in upgrading I4B or 
integrating CAPI into I4B, at all. He wants all applications to use CAPI. I 
have done a great deal of work to upgrade I4B and I see no problem in 
extending "i4bcapimgr", which converts CAPI signals into generic I4B signals. 
Then after that, the generic I4B signals are converted into CAPI signals, 
which means that passive and active cards will follow the same path.

Then there is no need for Thomas's kernel CAPI manager. I you want to have 
something in the kernel, it is much simpler to write a new B-channel driver 
like "/dev/i4btel" than having to implement support for CAPI, register a CAPI 
manager and have all those wasted timers and state-machines.

I think it will be easier to add new  "user interfaces" or "application 
interfaces", when all signals, no matter where they are coming from, are 
transformed into some standard signals first, and then sent into the 
different translators. Currently there are two translators: i4b_capidrv.c and 
i4b_i4bdrv.c in /sys/i4b/layer4 . Adding a new translator will then be very 
easy. I think it is not so smart to design a system to only speak one 
protocol. Then you get very bound up. From my point of view it is much easier 
to write a protocol translator, than having to port the applications in 
question.


A problem with Thomas' CAPI implementation is that the applications are 
required to have timers and statemachines to detect missing frames and 
errors. In my CAPI implementation this is not needed at all. The kernel will 
keep track of missing signals, and if the system is out of memory, a flag 
will be set so that error is returned to the application at next read. And 
the CAPI library will require that the application is restarted, closing all 
active calls. This flag will only be set if an mbuf used for signalling is 
lost. If B-channel mbufs are lost, nothing will happen. The CAPI applications 
I have seen so far does not have any timers checking anything at all and 
solely rely on the kernel. So therefore I see little use in passing CAPI 
frames directly from hardware to application. It is best if the kernel does 
some processing and checking, and maybe decodes the contents into "struct 
call_desc" before passing the information to a translator.


One thing I have noticed is that some parts of I4B has been copied from Linux. 
For example in the official version of I4B in the file 
"/sys/i4b/include/i4b_l3l4.h" there is "i4l_driver_bchan_linktab" and 
"i4l_isdn_bchan_linktab". I am not sure who started I4B, but maybe Hellmuth 
can explain why this is like it is? But because it comes from Linux, this is 
no reason we should keep it. So I am actually glad I did such a major 
rewrite. I have very bad experience copying code, even my own :-)


My plan is currently to add E1 support in software and hardware, before 
Christmas. So maybe we can do some SMP benchmarking then?


--HPS