On Thu, 7 May 2009, Pantelis Koukousoulas wrote: > 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). Let's not implement "wildcard" claiming. That will simplify matters. > > 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). One bad side effect has to do with the lifetime of the claim. If the program actually using the port dies the file will remain open because of the sharing, so the port won't get released. > > 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. You don't understand the problem. Suppose a program tries to open a usbfs device file. How does the kernel know whether or not that process has opened the corresponding port file? I suppose we could search through all the fd's the process has, but that doesn't seem like a good approach. At least, I don't know of any other place where the kernel does that sort of thing. 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
