> It isn't as simple as it might sound. Heh, if it were simple we most likely wouldn't be having this discussion :) > A program could simply write a hub name and port number to a file. > But what format should we use for the hub name? Unfortunately I don't (yet) own a hub so the only port addresses I 've seen are of the form <bus>-<port>. I 'm not sure if Linux uses any different format for ports that belong to non-root hubs, or this is about something entirely different. > 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? I doubt it. At least most virtualization solutions I know of only offer a total of 8 to 31 "virtual ports". There are other performance problems that prevent offering more AFAICT and opening up to 8 files doesn't sound that horrible with today's platforms. On the other hand this could be a problem with "wildcard" claiming, i.e., userspace wanting to claim all ports in a large system. That doesn't sound very nice ;) (But still you would need quite a few hubs to e.g., have problems with ulimit and such). > > 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. Probably they should indeed share the port and deal with locking themselves. Sharing a port doesn't make any sense to me though and from what I can tell none of the apps that are the candidate clients for this infrastructure does any forking. Most likely, the app should fork before claiming the ports. Would there be any bad side-effects from forking causing shared ports? (I mean side-effects that are not limited to 2 programs accessing the same port and thus causing a device that does not function. This is clearly a problem for the userspace program, not the kernel). > > 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? It should probably just allow it for either process that has the fd. If the user program claimed a port and then forked, it was probably intending to share ports. > 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? I don't think we should have such involved trickery unless there are security / correctness requirements that make it absolutely neccessary. So far, my view is 1 fd per port, if userspace wants to share it, it is their problem unless that causes other stuff to break. OTOH, I think I 'd really need to e.g., implement a prototype before I can contribute more fruitfully to this discussion (about the "how"). Or at least a more complete theoretical model. All my arguments right now are just hand-waving :) There are clearly difficult decisions to be made, though that is true with any API, especially in the kernel where you can't just "go back" very easily once you committed to a solution. 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
