Date: Sat, 31 Dec 2005 14:50:10 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: Anish Mistry <mistry.7@osu.edu> Cc: freebsd-usb@freebsd.org Subject: Re: My USB controller driver Message-ID: <200512311450.10673.hselasky@c2i.net> In-Reply-To: <200512310123.15212.mistry.7@osu.edu> References: <200512302235.40874.hselasky@c2i.net> <200512310123.15212.mistry.7@osu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 31 December 2005 07:23, Anish Mistry wrote: > On Friday 30 December 2005 04:35 pm, Hans Petter Selasky wrote: > > Hi, > > > > I just want to remind you of my USB controller driver for FreeBSD. > > I have now created a new homepage for it: > > > > http://www.turbocat.net/~hselasky/usb4bsd > > > > The sources are currently part of my ISDN4BSD driver, and can be > > downloaded by running the following command, if one has got > > Subversion installed: > > > > svn --username anonsvn --password anonsvn checkout > > svn://svn.turbocat.net/i4b > > > > This should make it very easy to make patches against my driver, if > > anyone has any suggestions for improvements. For those of you not > > familiar with svn, a patch can be produced by running the command > > "svn diff". > > > > It is also possible to browse the sources at the homepage without > > having to install SVN. > > Do you have any ETA or progress report on merging these changes into > the tree? To get the locking stuff right, I think that FreeBSD 7 will have a new USB system. FreeBSD 5/6 will continue using the old USB system until further. There are no concrete plans made yet. Maybe this about locking is not so easy to see. According to a FreeBSD committer, one of the goals about FreeBSD 7 will be to get the system less dependent on Giant. For example one wants all network drivers out of Giant. There are USB network drivers also. This means that the USB transfer callbacks must be called with a custom lock locked and not Giant, else one gets a locking order reversal problem somewhere in the system. This sounds simple, but just try to implement it, and you will see another problem pop up: Central USB procedures sleep for various reasons. For example "bus_dma" is used to allocate memory on the fly. If one is in a timeout and wants to start a USB transfer, it is not a good idea to sleep, and then one needs another thread and _no_, just forget it. One can do it, but trust me, it make things terribly complicated. Look at this analogy: mtx_unlock(&sc->sc_mtx); /* "uiomove()" can sleep so one * needs to make a wrapper, exiting * the mutex and checking things */ error = uiomove(cp, n, uio); Every time one re-enters a mutex, one has to check things, hence something can have happended like that the device was unplugged, file closed, transfer stopped ... whatever. In the existing USB system one simply does not care at all about this. One can find "uiomove" called without any checks afterwards, several places in the existing USB device drivers. Most of the time nothing goes wrong. But the panic screen should not be the only motivation to do something. mtx_lock(&sc->sc_mtx); sce->state &= ~context_bit; Extra checking, like shown below and its accompanying complexity can be completly elliminated if the USB system is non-blocking: if(sce->state & UGEN_CLOSING) { wakeup(sce); error = EINTR; } return error; Of course some things will be blocking, but these functions can be factored out to be called from attach/detach only. That is what I have done. I don't know if anyone else has tried to get the USB system out of Giant. It would be interesting to hear their experiences. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200512311450.10673.hselasky>