Date: Sun, 14 Aug 2005 17:32:51 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: Michael Reifenberger <mike@reifenberger.com> Cc: freebsd-isdn@freebsd.org Subject: Re: New ISDN driver Message-ID: <200508141732.53167.hselasky@c2i.net> In-Reply-To: <20050814100345.H98474@fw.reifenberger.com> References: <20050812143625.86D8C1177E@bert.int.kts.org> <200508121816.51020.hselasky@c2i.net> <20050814100345.H98474@fw.reifenberger.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=20 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=20 speaking about FreeBSD, everything has been brought into my new system,=20 except what you find in /sys/i4b/layer1/ifpi2 and /sys/i4b/layer1/capi . I= =20 plan to port the ifpi2 driver when I have got some time, but I think that o= ne=20 will be better off buying a new HFC-S PCIA ISDN card or some of the support= ed=20 USB adapters. > - Is NETGRAPH (i4bing) supported/testet (just necessary for me)? i4bing does currently not compile on FreeBSD-7, but it might compile on=20 =46reeBSD 5.4, and I will fix that, hence the Netgraph system has been upda= ted,=20 since I last checked. But the file is there and if you do a one by one line= =20 comparison with the official version, is should not take very long to updat= e=20 it and get it compiling again. But if you just want to set up an IP link,=20 "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 to= p=20 of I4B and C4B, that switches messages by controller, it should be possible= =20 to use both systems at the same time. The problem is only that the users wi= ll=20 be confused by all the different controller numbers. So actually it would b= e=20 very nice if C4B could allocate an "i4b controller" and use that controller= =20 number. Here I am referring to my version of I4B. Another thing is the=20 "capi20.h" header files. They are completely different, and maybe someone=20 wants to review which is better, because we cannot have a CAPI system with= =20 two "capi20.h" header files. =46rom what I understand Thomas is not interrested in upgrading I4B or=20 integrating CAPI into I4B, at all. He wants all applications to use CAPI. I= =20 have done a great deal of work to upgrade I4B and I see no problem in=20 extending "i4bcapimgr", which converts CAPI signals into generic I4B signal= s.=20 Then after that, the generic I4B signals are converted into CAPI signals,=20 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= =20 something in the kernel, it is much simpler to write a new B-channel driver= =20 like "/dev/i4btel" than having to implement support for CAPI, register a CA= PI=20 manager and have all those wasted timers and state-machines. I think it will be easier to add new "user interfaces" or "application=20 interfaces", when all signals, no matter where they are coming from, are=20 transformed into some standard signals first, and then sent into the=20 different translators. Currently there are two translators: i4b_capidrv.c a= nd=20 i4b_i4bdrv.c in /sys/i4b/layer4 . Adding a new translator will then be very= =20 easy. I think it is not so smart to design a system to only speak one=20 protocol. Then you get very bound up. From my point of view it is much easi= er=20 to write a protocol translator, than having to port the applications in=20 question. A problem with Thomas' CAPI implementation is that the applications are=20 required to have timers and statemachines to detect missing frames and=20 errors. In my CAPI implementation this is not needed at all. The kernel wil= l=20 keep track of missing signals, and if the system is out of memory, a flag=20 will be set so that error is returned to the application at next read. And= =20 the CAPI library will require that the application is restarted, closing al= l=20 active calls. This flag will only be set if an mbuf used for signalling is= =20 lost. If B-channel mbufs are lost, nothing will happen. The CAPI applicatio= ns=20 I have seen so far does not have any timers checking anything at all and=20 solely rely on the kernel. So therefore I see little use in passing CAPI=20 frames directly from hardware to application. It is best if the kernel does= =20 some processing and checking, and maybe decodes the contents into "struct=20 call_desc" before passing the information to a translator. One thing I have noticed is that some parts of I4B has been copied from Lin= ux.=20 =46or example in the official version of I4B in the file=20 "/sys/i4b/include/i4b_l3l4.h" there is "i4l_driver_bchan_linktab" and=20 "i4l_isdn_bchan_linktab". I am not sure who started I4B, but maybe Hellmuth= =20 can explain why this is like it is? But because it comes from Linux, this i= s=20 no reason we should keep it. So I am actually glad I did such a major=20 rewrite. I have very bad experience copying code, even my own :-) My plan is currently to add E1 support in software and hardware, before=20 Christmas. So maybe we can do some SMP benchmarking then? =2D-HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508141732.53167.hselasky>