usb4bsd patch review

[M. Warner Losh]

In message: <48ADA66A.3040906 at FreeBSD.org>
            Kris Kennaway <kris at freebsd.org> writes:
: Hans Petter Selasky wrote:
: > On Thursday 21 August 2008, Kris Kennaway wrote:
: >> Hans Petter Selasky wrote:
: >>> On Thursday 21 August 2008, Kris Kennaway wrote:
: >>>> Hans Petter Selasky wrote:
: >>>>>> * How much of the userland support is incomplete or in flux, and what
: >>>>>> functionality is missing for users of the usb2 code until it is
: >>>>>> finished?
: >>>>> The USB userland library is nearly complete. All it lacks is proper
: >>>>> documentation:
: >>>>>
: >>>>> svn --username anonsvn --password anonsvn \
: >>>>>       checkout svn://svn.turbocat.net/i4b/trunk/libusb20
: >>>>>
: >>>>> The USB config utility is also starting to become finished. It will be
: >>>>> renamed to usbconfig. Currently it is called usbview :
: >>>>>
: >>>>> svn --username anonsvn --password anonsvn \
: >>>>>       checkout svn://svn.turbocat.net/i4b/trunk/usbview
: >>>> So...what functionality is missing for users of the usb2 code until it
: >>>> is finished?
: >>>>
: >>>> Stated even more clearly, what things will users of the USB2 code not be
: >>>> able to do until the above userland code is imported?
: >>>>
: >>>> Seriously, I'm trying to understand this!
: >>> Hi,
: >>>
: >>> There are some USB drivers which run in userland that will not work until
: >>> this library is complete. These are currently not part of the FreeBSD
: >>> distribution. You find them in /usr/ports :
: >>>
: >>> grep libusb /usr/ports/INDEX
: >>>
: >>> The kernel USB drivers provided under /sys/dev/usb2 do not directly
: >>> depend on any userland utilities, but rather indirectly through the TTY,
: >>> KBD, NET ...
: >>>
: >>> One exception is the USB mouse driver which depends on "moused", and
: >>> currently have some warnings because moused tries to load the old ums
: >>> module, which fails.
: >> OK, now we're approaching half way.  The moused thing should be
: >> documented somewhere with a workaround (or fix).  If the new ums2 module
: >> is present before moused is started will it still try to load the old
: >> one?  Is there another workaround?
: > 
: > Hi,
: > 
: > What happens is this:
: > 
: > 1. devd reports "ums0" like before.
: > 2. moused is started
: > 3. moused tries to kldload ums
: > 4. The ums module depens on the usb module which is also tried loaded.
: > 5. Loading the usb module fails.
: > 6. moused finally tries to open /dev/ums0 and the mouse works like before.
: > 
: > ums0: <Microsoft Microsoft 3-Button Mouse with IntelliEye(TM), class 0/0, rev 
: > 1.10/3.00, addr 3> on usbus3
: > ums0: 3 buttons and [XYZ] coordinates
: > Symlink: ums0 -> usb3.3.0.16
: > 
: > module_register: module pci/uhci already exists!
: > Module pci/uhci failed to register: 17
: > module_register: module cardbus/uhci already exists!
: > Module cardbus/uhci failed to register: 17
: > module_register: module pci/ohci already exists!
: > Module pci/ohci failed to register: 17
: > module_register: module cardbus/ohci already exists!
: > Module cardbus/ohci failed to register: 17
: > module_register: module pci/ehci already exists!
: > Module pci/ehci failed to register: 17
: > module_register: module cardbus/ehci already exists!
: > Module cardbus/ehci failed to register: 17
: > KLD ums.ko: depends on usb - not available
: 
: OK, so just cosmetic.  It kind of sounds like moused is doing the wrong 
: thing, but this can hopefully be fixed later.
: 
: >> What about the second thing: usbconfig?
: > 
: > The USB stack will work fine without "usbconfig". Its purpose is mostly to 
: > view the currently attached USB devices, where the USB devices are located 
: > and to select a non-default USB configuration. One thing which might be 
: > missed is to change owner and permission of a USB device, which means you 
: > must be either UID=root or GID=OPERATOR to be able to use USB devices that 
: > create devices under /dev/ .
: 
: OK great, this isn't critical either.  I think all of the issues I 
: raised are agreed upon now!
: 
: Unfortunately since Alfred is going away for 3 weeks it looks like that 
: is now going to put this on hold for a bit.  It's probably a good thing 
: that the initial import was delayed actually, since he is going to need 
: to be available for the inevitable followup work after it gets imported, 
: and leaving 3 days after the planned import would have really hurt that 
: process.
: 
: Unless someone else comes forward to take over from Alfred, here's what 
: I recommend as a plan:
: 
: * post the revised diff with the minor changes/bits left out that we 
: have agreed upon.  Users can continue to test this commit candidate 
: while Alfred is away.
: 
: * When Alfred gets back and has a block of free time, he will proceed 
: with the import and handle followup commits to fix issues that are 
: identified.
: 
: * If the "commit candidate diff" changes in the meantime due to bug 
: fixes etc, then you should keep the mailing list updated regularly with 
: a pointer to the latest version of the commit candidate diff.  Other new 
: stuff like the forthcoming userland changes should stay out of this 
: first diff for now so we don't invalidate things that have already been 
: reviewed.
: 
: * In the meantime you can continue to work on the missing stuff like 
: manpages, userland, unbundling drivers, etc.  With luck, some or all of 
: this will also be ready by the time Alfred gets back, and you can post a 
: second diff for review and subsequent commit around the same time.
: 
: How does this plan sound to you?

I'd be willing to pick up the ball a little bit here: There's some
base system (not driver) issues that can be resolved so that we can
improve the quality of the commit candidates and underlying FreeBSD.

Warner