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

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> 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?

When user space gets an event saying the bus itself exists and asks for
it to be scanned. The most obvious case where its currently broken is
partition tables on disks where you don't always want to read partition
tables automatically.

> 
> 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?

It means that the bus scanning occurs out of control of the virtualised
environment which might want to control what occurs

> 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).

If enumeration isn't automatic (or even more so if binding isn't always
automatic) then the problem doesn't occur.

> 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.

Given the layout of devices can change fairly arbitarily would the
ability to claim specific device identifiers via libusb do the job any
better.

ie would it be better to expose an interface via libusb that was
essentially

	reserve_for_userspace(vendorid, devid);