On Sun, May 3, 2009 at 9:58 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Sun, 3 May 2009, Pantelis Koukousoulas wrote: > >> Hi, >> >> > It has not been worked on. There was a lot of discussion, and we sort >> > of reached a consensus about what was needed, but no patches have been >> > posted. >> >> Could you please point me towards / inform me about what was that consensus? >> I got lost in the various threads after a while :) > > As I recall, it went something like this: > > There should be a mechanism for userspace to influence > automatic binding of the generic driver to USB devices. If > a program wants to gain control a newly-detected device then > it can; otherwise the generic driver will handle it in the > usual way. > > Also, there should be some way for a user program to take > control of an existing device. > > When a user program gains control of a device, the kernel > won't automatically install any configuration and won't probe > for drivers when the config is changed. Instead the user > program is granted full control over all the interfaces. It > can do Set-Config or Reset whenever it wants. > > Other programs will be allowed to do harmless input via usbfs > (like reading the descriptors from the device file) but not any > ioctls. And nobody will be allowed to write to the > bConfigurationValue sysfs attribute. > > When the user program gives up control of a device, the kernel > won't automatically issue any Set-Interface requests (I'm > not sure this is really a good idea). It also won't change the > configuration or automatically probe for interface drivers. > > This doesn't answer all the remaining questions, but it is a start. That was very informative, thanks :) >> Surely the goal is to "grab" devices. But since these grabs must persist across >> resets/disconnects/reconnects we would effectively grab "ports", right? > > No, I don't think so. It doesn't make sense to grab a port. Instead > we would allow the program to intercept all new device registrations > somehow and decide whether or not to take control of the device. I 'm a bit worried about how feasible it will be to write a userspace program that interacts with the kernel in such a way. Wouldn't that mean that the kernel's hotplug subsystem would now have to wait approval from userspace on whether to go on its way configuring a device or not? It looks like it would be easier / more risk-free to be able to claim a port / port range (or even a full hub if this makes implementation easier) even before any device is connected there if so desired. E.g., have a usb_userspace alternative driver to usb_generic and ask the kernel to bind that one to whichever device connects to any port of hub X instead of usb_generic. Then usb_userspace can implement the policy of making sure all the device's interfaces are created already bound to usbfs and the particular process and won't be accessible to anyone else etc etc (as described by you above). Claiming a port / port range could be implemented by having a filter in the kernel that decides whether to bind usb_generic or usb_alternative/usb_userspace based on the bus.port address (thus no need to set configuration or read descriptors). Such a resource allocation mechanism for USB might also be helpful to the multi-seat people (just connect a couple of hubs to the root hub - where the hubs could be actually embedded inside e.g., the keyboard - and assign each hub to a seat). The userspace program just informs the kernel (e.g., through sysfs) about the ports/hubs it wants to claim. There is no kernel<->userspace interaction during hotplug, communication stays one-way only. I 'm sorry if this sounds way misguided or worse, I 'm still in the process of figuring this stuff out. Thanks, Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
