Hi Siarzhuk, Siarzhuk Zharski <zharik@xxxxxx> wrote: > > 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. > >> PS: Axel, do you remember our private e-mail discussion about > >> donating my drivers to OBOS some month ago? You still can > > > come to me and get it. =-) > > Thanks :) > > What drivers from yours are compatible with out license, i.e. not > > GPLd? > That was an original question. =-)) All my work is "compatible" in > this > meaning. =-) All drivers are under BSD/MIT license. I don't used > GPLed > sources. Good to know! > 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 :) > Well. The [draft of my] final decision: =-) I'm agree to > "participate" > in OBOS development by donating my code, further supporting it, > adapting > to OBOS USB stack etc... Unfortunately, I can give guaranties for > supporting and developing _only_ my modules and helping in fixing > possible related problems in other parts of system if its depend on > my > modules. > In case if this "restriction" is not very significant for OBOS Team - > > I'll be glad to add prefix "(open)BeOS" to my driver descriptions. =- > ))) Nobody can give any guarantees about anything in here, and we don't ask for it. If I would turn around tomorrow to be a gardener full time and only, nobody will stop me (but don't be afraid, I won't :-)). Of course, it's great when you develop something for us, and maintain the code further on until it becomes legacy. But we cannot ask for this, we just appreciate it :-) You don't have to add this prefix as all our drivers are BeOS drivers as well, but do as you feel like :-) Bye, Axel.