On Tue, 5 May 2009, Pantelis Koukousoulas wrote: > Heh, exactly, apologies for wrong choice of words :) If the ports are released > when their userspace owner dies, all is ok. > > >> So, it seems to me that we are all on the same page about what needs > >> to be done and also agree about the overview of how (new driver probed > >> before generic, some sort of file-based grabbing, etc). > > > > I'm open to suggestions for how the file-based grabbing should be > > implemented. > > I haven't yet given serious thought to the API, sorry (probably this will > happen next week) It isn't as simple as it might sound. A program could simply write a hub name and port number to a file. But what format should we use for the hub name? And where should the file be located? Maybe it would be easier if we used the hub's own usbfs device file. But if a program wanted to claim ports on lots of hubs then it would have to open lots of files; is that likely to be an issue? A more difficult question has to do with ownership. Suppose a program claims a particular port and then forks. Do both processes then own the port? They will share their open file references. When one of them tries to open the usbfs device file for the device attached to that port (or tries to do an ioctl to it), how does the kernel know whether or not to allow the operation? Based on the address of the task structure? Then only the parent process would really own the port. But the parent could die, and the file reference would remain open as long as the child was still alive. What if another process then ends up using that same task structure? 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
