In message: <20070627042616.GA27957@bcd.geek.com.au>
            Daniel Carosone <dan@geek.com.au> writes:
: On Tue, Jun 26, 2007 at 09:57:36PM -0600, M. Warner Losh wrote:
: > FreeBSD's mutexes protect data, while NetBSD splusb protects code.
: > The fine grain locking that's been introduced into recent NetBSD
: > versions might help change this, but it took FreeBSD 5 years to lock
: > down the kernel to the point where Giant doesn't cover much these
: > days.
: 
: I suspect the differences, from the perspective of a driver writer,
: need not be so great (even if the underlying mutex and scheduler
: implementations differ to a greater extent).  Moreover, I suggest
: Making It So would be a worthy goal in itself.

The idea in FreeBSD, before the hps stack hit the scene, was to keep
the client drivers (umass, ums, etc) using the same API, and then
reworking the stack itself to have better locking.  Hans Petter
Selasky's work suggests that no API changes might not be an attainable
goal, as he's made a number of changes to APIs for his locking work.
I've spent quite a bit of time studying his code, and I'm still unsure
if they are absolutely required or not.

The queueing and scheduling of usb requests makes it well suited to a
taskqueue + worker thread approach.  With careful design, it is my
hunch that one could construct a usb stack where the locking and
synchronization behind the scenes doesn't matter.  However, my hunch
isn't borne out by any currently existing usb stack: they all have
locking issues.

Open USBDI also doesn't seem to have been addressed by any of the BSD
stacks.

: Where does DragonFly fit in this spectrum, as yet a different take on
: the model?

Unsure, but given that it is mostly message passing, and usb is
mosting message passing, and DF's main synchronization primitive is
message passing, it might be a good fit.  I've not studied enough of
the DF code to know how it could fit in.

: > If there's a good way around these issues that I've not seen, I'm all
: > ears.
: 
: Yeah; I guess the point is that the usb code (with the commonality it
: already has) is probably the best and most convenient concrete example
: with which to explore exactly this question.

The problem may be one of acceptance.  The FreeBSD integration of usb
wasn't done very well.  This lead to a lot of problems.  It was always
a foreign stack bolted onto the side of FreeBSD that barely worked.
While much progress has been made to promote the different parts of
usb, especially the pci <-> usb host adapters, a big part of the
motivation to clean things up in the FreeBSD tree.  The compat macros
held improvements in FreeBSD back because they were difficult to
penetrate (despite being actually rather simple on the whole).  This
has lead to a general distrust of excessive macros from members of the
FreeBSD community as a way to achieve portability.  You'd be playing
to a skeptical audience at best.

If one were to go down this path, one would need to make sure that the
stack worked well on all the different BSDs without doing a lot of
obfuscating macros to make it happen before the 'common layer' is
designed.  At least that's my hunch.

However, my goals are more modest than all of this: I'd love to see
usbdevs shared as a first step.  If we can't even arrange that, then
what hope is there for the rest?

Warner