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

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.
> I consider large portions of his code unreadable and as such unmaintainable
> for me and i will not import this code to FreeBSD, not as a whole and not
> as pieces. In case anyone wants to merge and/or import Hans Petters driver
> in its current form into FreeBSD she/he is with regards to me free to do
> so.

I agree that there were some things that were not so good in the driver last 
year, but I have tried to fix that now. Have you looked at the source code 
this time. Can you give an example of what is not so good and why?

> Last time i looked at this, several drivers which are essential were marked
> as not tested and/or not available.

The ISAC/HSCX framework has been throughly tested. When one such device works 
all the others should work aswell. It is the same chipset. "Don't know if 
they work" means that I have not tested every single card, hence I have not 
got access to that hardware, but I expect it to work hence I have tested one 
of those cards with ISAC/HSCX. Also I have got reports back that it works. By 
the way: The ISDN cards that you refer all use buffers of less than 64 bytes 
(8ms), and does not provide reliable data transfer when one starts loading 
the kernel. A good ISDN card has a buffer of 100ms at least. These are for 
example the USB devices and HFC-S XXX . These have all been tested.

> Several times i have requested that Hans Petter should clean up his code
> and break it into overseeable patches so new functionality and bug fixes
> could be imported incrementally without breaking running code, but he is
> as it looks to me either not able or not willing to do so.

I have already spent some weeks on CAPI. The existing I4B system is basically 
wrong. It does not support mutexes, and you cannot add mutex support in the 
form of adding a few lines here and there, which is the impression I get. 
Then you will end up with reverse locking order problems and worse. The whole 
system must be redesigned. You suggested doing one driver at a time, but 
please tell me how this is possible. For example, if you want each controller 
under each its lock, what lock should the channel drivers, "/dev/i4bxxx" use? 
If you let each channel driver be under each its lock to, then the channel 
drivers cannot call into I4B while holding that lock, hence I4B is calling 
the channel drivers with the controller lock locked. You cannot unlock the 
channel driver lock before calling into I4B either, hence you get trouble 
with the state of the channel driver: What happens if that channel is 
disconnected exactly at the unlocked instruction, and at the same time it is 
trying to call into I4B. Then you might want to use some increment/decrement 
refcount, but suddenly you understand that that is not possible, because then 
the callback will be blocking and you have call the interrupt handler from a 
separate thread, which is just waisted CPU if the interrupt happens more than 
250 times per second.

> With regards to c4b:
> Thomas has gotten a commit bit and is working to get everything up and
> running to import c4b asap.
> I think its absolute essential and necessary to get c4b into FreeBSD and
> it might be that this has also a positive impact on the future life of i4b.

There are passive multichannel devices too. Adding support for SS7 or whatever 
they use should not be a very big task. The layer 1 driver is the least 
problem. I opt for passive cards.

On a second thought, active cards can pose a security risk to the system. 
Doesn't these cards use DMA and have full access to the system memory?

Third, when you want to make an embedded product, it is going to be much more 
expensive if you use CAPI. Just think about the overhead having to 
encode/decode protocols twice.

Are you interested in building up support for passive T1 cards?

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

Visit your host, monkey.org