lkml.org 
[lkml]   [2009]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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



    \
     
     \ /
      Last update: 2009-05-22 17:15    [W:3.581 / U:0.372 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site