Hallo, Axel,
I'd say this would be the developer's decision :-)
For example, the BeOS IDE driver contains code for all devices in one driver. I personally don't like this, and I would prefer the FreeBSD way of doing. But if that way would cause any disadvantages on the users side (i.e. manual configuration), I probably wouldn't do it.
It's also the question of how much code is shared. If there is only a small bunch of code necessary for every device, it might be unreasonably to split the driver into several ones.
IMO more than 80% of code will be duplicated in case of separate implementations. =-( If you look into my CVS repository: http://cvs.sourceforge.net/viewcvs.py/sis4be/usb_scsi/ - everything but the proto_bulk.* and proto_cbi.* files is shareable code. I've developed this with expandability in mind. =-)
If you can put them into a separate module, then this would probably be the way I'd go, if not, a single driver can do it as well. It also depends on how many drivers would result out of this split - BeOS doesn't like to have too many drivers as it has to ask all of them for devices on startup, which makes a difference if there is 1 driver or 100 of them.
Some words about my projects. You can see them all in my CVS repository
- usb_serial: (http://www.bebits.com/app/3433)
the implementation of standard (USB class 2) CDC ACM compatible communication devices. Also supports FTDI-base and Prolific-base USB-RS232 adapters. Works perfect for me. And there are no problem reports from users too. =-) Note that it requires and heavily uses "tty" module for implementing serial port. Do you have plans to recreate this [absolutely undocumented] module in OBOS too? As far as I know all those serial port-like devices (pty, zz, ltmodem, pctel) uses this "tty" module. =-|
As you are obviously now familiar with it, would you be interested in writing it for OpenBeOS? :-)
- usb_scsi:
the implementation of standard (USB class 8) mass storage devices. I have performed some "close testing" and there are many success stories about it in my e-mail inbox. Both bulk-only and CB[I] protocols are implemented. I'm going to publish it on BeBits.com ASAP...
There are two ways of maintaining your drivers for us:
a) we get it from you and any updates you do to your sis4b repository
b) you get write access to our repository and move your driver development over there
Of course, I would prefer b), because there is less work involved (probably for both sides). Of course, that would make you kinda part of the team, and I don't know if you want this ;-))
And what about that sync bug in the SiS 7018 driver? (couldn't resist to ask) :-)
Yes. I understand you. =-) I'm going to rewrite this one. It was my first attempt in BeOS kernel space. =-) Now I can do the same things in more nice way. =-))
To tell you truth, I'm waiting for OBOS MediaKit to make my driver for it. Sorry, but I don't keep track the OBOS MediaKit progressing till now: Is it possible to use it at the moment and write drivers for it? =-)
Our Media Kit can run as a replacement for Be's, so of course, you could write drivers for it. But there is no special new interface for drivers, it is currently using the ones developed by Be, and I don't see a problem with it.
Marcus is designing a new audio driver interface, but I don't know if it is intended to be ready for R1 or later. I don't think it makes much sense to wait :)
Kind Regards,
S.Zharski