Messages in this thread | | | Date | Fri, 22 May 2009 11:12:28 -0400 (EDT) | From | Alan Stern <> | Subject | Re: How to tell whether a struct file is held by a process? |
| |
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
| |