Re: How to tell whether a struct file is held by a process?

[Alan Stern]

On Fri, 22 May 2009, Kay Sievers wrote:

> On Fri, May 22, 2009 at 17:12, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> > Anyway, enumeration isn't the problem. Â The real problem has two parts:
> >
> > Â  Â  Â  Â Automatic probing and binding of kernel drivers, including
> > Â  Â  Â  Â selection and installation of a configuration (this really
> > Â  Â  Â  Â _does_ mess up virtualization).
> >
> > Â  Â  Â  Â The fact that a window exists immediately after the
> > Â  Â  Â  Â registration of a newly-detected device before a user
> > Â  Â  Â  Â process can lock the device file. Â During this window,
> > Â  Â  Â  Â other processes could open the file.
> >
> > The second part can be solved (among cooperating processes) by use of
> > port-lock files, with no kernel involvement. Â The first part does
> > require a kernel interface of some sort, but it wouldn't have to be
> > complicated. Â The mere fact that a port-lock file was open could be
> > enough to prevent automatic configuration, probing, and binding.
> >
> > Does this seem like reasonable approach?
> 
> Would releasing the "lock" trigger a kernel-driver-binding call?

No.  If the lock owner wants to bind kernel drivers, it can use the
existing API in libusb after releasing the lock.  This might cause
problems if the owning process terminates abnormally, but I think we
can live with that.

> The lock will always lock all devices of a specific hub?

The idea is that there will be one lock file per port.  So for example, 
a hub device with four ports might contain inside its sysfs device 
directory: ports/1, ..., ports/4.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/