Date: Thu, 21 Aug 2008 19:31:22 +0200 From: Kris Kennaway <kris@FreeBSD.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: usb4bsd patch review [was Re: ...] Message-ID: <48ADA66A.3040906@FreeBSD.org> In-Reply-To: <200808211856.47568.hselasky@c2i.net> References: <20080818205914.GJ16977@elvis.mu.org> <200808211840.13109.hselasky@c2i.net> <48AD9B9A.8070403@FreeBSD.org> <200808211856.47568.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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? Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48ADA66A.3040906>