On Thu, May 7, 2009 at 23:18, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 7 May 2009, Kay Sievers wrote: >> On Thu, May 7, 2009 at 21:55, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> > There is a proposal afoot to give user programs the ability to claim >> > ownership of an entire USB device, rather than just individual >> > interfaces. In fact, we'd like processes to be able to own whatever >> > device gets plugged into a particular port on a particular hub. >> > >> > The question is how the API should work. A simple approach is to have >> > a sysfs or usbfs file correspond to each port; when a process opens the >> > file it would be granted ownership of any device plugged into that >> > port. Since the file is automatically closed when the process ends, we >> > wouldn't have to worry about ownership never getting released. >> > >> > But there's a snag. When a process goes to open the usbfs file for a >> > device, the kernel needs to know whether or not the process owns that >> > device. In other words, we need to figure out whether or not the >> > process has opened the corresponding port file. >> > >> > Is there a simple way to do this? Is it reasonable to search through >> > all the process's fd's, looking for one that matches a particular >> > inode? >> > >> > Or would a completely different API approach be better? >> >> You have one file per device, and that file has normal unix file >> permissions. Userspace can grant access to that file by ownership or >> by adding an ACL. What else do we need? > > We need the ability to prevent the kernel from automatically > configuring a device. We need the ability to prevent kernel drivers > from binding to a device before userspace programs get a chance. > >> Why would the kernel care who >> opened the file, when the one was able to get through the normal file >> access check? > > Access checks can't be used, because programs want to stake their claim > to the device (and its file) even before the device has been plugged > in. So there's no file and no ACL to set. I see. Can't userspace just unbind a possible driver, which is supported by libusub? Other such use-cases do that, like the UPS userspace drivers, which just unbind the device from a possible in-kernel driver to take it over. Or is that a specific requirement where things would go wrong when the kernel binds to a device first? Kay -- 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
