Date: Sun, 14 Aug 2005 21:25:33 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: freebsd-isdn@freebsd.org Subject: Re: New ISDN driver Message-ID: <200508142125.33718.hselasky@c2i.net> In-Reply-To: <200508141732.53167.hselasky@c2i.net> References: <20050812143625.86D8C1177E@bert.int.kts.org> <20050814100345.H98474@fw.reifenberger.com> <200508141732.53167.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 14 August 2005 17:32, Hans Petter Selasky wrote: > 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@c2i.net> > > > To: freebsd-isdn@freebsd.org, hellmuth.michaelis@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? I think I have found a serious locking problem in C4B. The function "kcapi_put_message()" uses "sx_xlock()" to protect data. Do you know what that means. This function cannot be called while holding a mutex, neither can it be called from interrupt handlers and timeouts! The reason is that "sx_xlock()" can sleep! And this function is very important, because it is used to receive/transmit all CAPI messages, which is almost everything that is transmitted through "/dev/capi20". This means that one has to create a separate thread that will forward mbufs to "kcapi_put_message()". Simply wasted CPU. Also sx-locks are very depreceated according to "man sx", and "mutexes are inherently more efficient". At the moment there is contention on a "sx" lock, it will sleep, and the kernel is going for a panic or deadlock, if a mutex is held. I suspect there is a reason that Thomas uses an sx-lock, and to change this, maybe the whole of C4B must be redone. Because solving locking problems like this is not very easy. Or is there something I have over-looked ? Any comments ? --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508142125.33718.hselasky>