[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New ISDN driver

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_(_at_)_c2i_(_dot_)_net>
> > > To: freebsd-isdn_(_at_)_freebsd_(_dot_)_org, hellmuth_(_dot_)_michaelis_(_at_)_t-online_(_dot_)_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 ?

freebsd-isdn_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-isdn-unsubscribe_(_at_)_freebsd_(_dot_)_org"