>> 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 ;) > > Let's not implement "wildcard" claiming. That will simplify matters. Agreed. I was against this feature anyway, so I won't miss it :) >> 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. True, but still this doesn't sound like a problem for the kernel. For what we know, there may even be valid use-cases for keeping the port claimed. Otherwise, leaking ports is like leaking file descriptors, a userspace bug. The user can easily figure out what the problem is with fuser/lsof, kill the remaining process(es) that reference the fd(s) and the port(s) will be available again. Then a bug can be filed so that the offending package can be fixed. > >> > 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. Indeed I hadn't understood the problem. What if the process wrote its PID to the port file besides just opening it? Opening the file ensures nobody else can open it and writing your PID there allows usage of ioctls etc. The semantics of close will be that the file is emptied. We will probably have to come up with something better than that though. 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
