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

[Alan Stern]

On Fri, 22 May 2009, Alan Cox wrote:

> > the OP), is to make there be a global "prevent kernel drivers from
> > autobinding to  devices on his port" flag, and manage the rest with
> > lockfiles in userspace.
> 
> Your "practical example" seems to bear no relation to the other stuff,
> its a separate topic altogether.
> 
> Yes a "don't probe this port" would make sense. The fact kernel space
> probes the USB devices by default like the fact we probe partitions by
> default and scan scsi busses by default are all really mistakes inherited
> from traditional OS designs which also mess up virtualisation the same
> way.

I don't understand this comment.  By "probe" I assume you mean
"initialize and enumerate", as opposed to calling various drivers'
probe() routines -- let me know if this isn't what you meant.  If the
kernel didn't initialize and enumerate devices by default, then when
would they get initialized and enumerated?

If your answer is "When requested by a user process", then I'll go on
to ask: What about devices containing the root filesystem, the system 
console, and so on?

And just how does initialization and enumeration mess up 
virtualization?

> So add a skip_ports= facility to the usb core code (or a general
> auto_enumerate=0 and a udev interface to trigger scanning so your udev
> rules can enumerate just the ports you want). That is probably cleaner
> because it makes the identification of ports rather cleaner and clearer.

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?

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/