On Mon, 4 May 2009, Pantelis Koukousoulas wrote: > >> 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? That's right, it would -- provided a program had registered its interest in vetting all new devices. If no programs were interested then everything would proceed normally. > 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. Is what I described really any different from simply claiming all the unoccupied ports on all hubs? > 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). There's no need to go into such low-level details at this point. We're still discussing the high-level overview. > 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). Thereby essentially allowing multiple device to be virtualized by different programs. That's a good point. > 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. It can't be totally one way. Otherwise the kernel wouldn't be able to inform the program when a new device was plugged into one of the ports. What happens if a device the program isn't interested in gets plugged into one of the ports it has claimed? Or what happens if a device the program _is_ interested in gets plugged into an unclaimed port? To handle these situations, isn't it better to do the claiming based on the device ID rather than on the port? > I 'm sorry if this sounds way misguided or worse, I 'm still in the > process of figuring this > stuff out. So are we all... Alan Stern -- 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
