[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New ISDN driver
- To: Michael Reifenberger <mike_(_at_)_reifenberger_(_dot_)_com>
- Subject: Re: New ISDN driver
- From: Hans Petter Selasky <hselasky_(_at_)_c2i_(_dot_)_net>
- Date: Sun, 14 Aug 2005 17:32:51 +0200
- Cc: freebsd-isdn_(_at_)_freebsd_(_dot_)_org
- Reply-to: hselasky_(_at_)_c2i_(_dot_)_net
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
> - 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
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?
freebsd-isdn_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-isdn-unsubscribe_(_at_)_freebsd_(_dot_)_org"