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 Message-ID: <200508121816.51020.hselasky@c2i.net> In-Reply-To: <20050812143625.86D8C1177E@bert.int.kts.org> References: <20050812143625.86D8C1177E@bert.int.kts.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508121816.51020.hselasky>