Attaching ugen to all usb devices

[Anish Mistry]

On Monday 25 December 2006 17:52, Hans Petter Selasky wrote:
> On Monday 25 December 2006 21:38, M. Warner Losh wrote:
> > In message: <200612251456.42770.amistry at am-productions.biz>
> >
> >             Anish Mistry <amistry at am-productions.biz> writes:
> > :  Many usb devices can be attached as different devices along
> > : with being functional with some libusb app that requires ugen.
> > : eg.  HP PSC Printers will attach as ulpt, if ulpt isn't loaded
> > : umass can attach to access the card slot, if neither of these
> > : are loaded ugen will attach which is required to run the hplip
> > : vendor software so that the printer, scanner, and fax machine
> > : can be accessed.
> >
> > You should review how the device presents itself to the system. 
> > If both umass and ulpt attach to it, it should be possible to
> > make them both attach at the same time.
> >
> > As for ugen, one could easily hack uhub to allow this kind of
> > access. ugen really shouldn't be attaching to any device at all,
> > but instead the usb bus (aka uhub) should allow ugen-like acess
> > to each of the devices.
>
> Right.
>
> Here are some pointers:
>
> The core of your problem is "usbd_set_config()". Whenever you set a
> new config value, you need to "device_delete_child()" all attached
> devices, and re-probe the "struct usbd_device *" in question. Maybe
> you can extend the already existing
> "usbd_remove_detached_devices()"?
>
> Try making a system where the USB device config value is always set
> from "usbd_probe_and_attach()", hence this function is always
> called from only one thread at a time!
>
> To force the system to re-call "usbd_probe_and_attach()", simply
> set "up->last_refcount = 0", then call "usb_needs_explore()". "up"
> is of type "struct usbd_port *".
>
> Maybe you should add a new field:
> udev->current_config_value.
>
> When "udev->probed == USBD_PROBED_SPECIFIC_AND_FOUND" disallow
> "/dev/ugenX" from setting the config value.
>
> Incorporate parts of ugen into "struct usbd_device":
>
> 1) Split ugen into two parts, /dev/ugenX and /dev/ugenX.X .
> 2) /dev/ugenX is created by "usbd_new_device()".
> 3) /dev/ugenX is removed by "usbd_free_device()".
> 4) /dev/ugenX.X is a regular device that attaches when "uaa.iface
> != NULL" and "uaa.usegeneric == 1". Maybe you have to remove
> "USBD_PROBED_GENERIC_AND_FOUND".
>
> There should be no problems in the USB stack regarding duplicate
> device attachment. If two devices start a transfer on the same
> interrupt endpoint, they will be served alternately, for example.
>
> > :  It would be very helpful to allow ulpt, umass, and ugen to all
> > : attach to the device.  This would allow full functionality. 
> > : Simultaneous access isn't necessary, but might be nice in the
> > : future.
> >
> > That would be a nightmare.  Trust me.  I've looked into it in the
> > past it was scary.
>
> Better switch the config value, so that the devices show up one by
> one.
>
> > :  The closest thing I can think of that allows similar behavior
> > : is vgapci that allow acpi_video and a drm driver to both access
> > : the video card.
> >
> > Well, it doesn't really.  newbus has a very strong notion of each
> > node in the tree has one and only one (or zero) devices attached.
>
> When do you think that you will have some patches ready?
I'm not sure.  I'd like to make some headway at least by the first 
since I don't know how much time I'm going to have after then.

-- 
Anish Mistry
amistry at am-productions.biz
AM Productions http://am-productions.biz/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20061226/9e8f859f/attachment.pgp