lkml.org 
[lkml]   [2006]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT PATCH] Remove devfs from 2.6.17
    Hi,

    Greg KH, le Sun 18 Jun 2006 16:12:04 -0700, a écrit :
    > On Mon, Jun 19, 2006 at 01:00:41AM +0200, Samuel Thibault wrote:
    > > - With udev, this just cannot work. As explained in an earlier thread,
    > > even using a special filesystem that would report the opening attempt
    > > to udevd wouldn't work fine since udevd takes time for creating the
    > > device, and hence the original program needs to be notified ; this
    > > becomes racy.
    > >
    > > So what is the correct way to do it? I can see two approaches:
    >
    > You forgot:
    > - use a static /dev if you want this.
    > No one is forcing you to use udev :)

    I can't choose the preference of the users of my program.

    > > Neither solution looks good to me... Just opening /dev/input/uinput
    > > should be sufficient, and udev doesn't let that for now.
    >
    > No, just do what the distros that use udev do today, load the needed
    > modules at boot time, based on the hardware that is present in the
    > system. This should work just fine for the uinput driver,

    No hardware correspond to the uinput driver.

    > and if not, simply add it to the list of modules that need to be
    > loaded every boot (each distro has a different place to put this
    > list), and you should be fine.

    I can't ask the users of my program to do that either (actually, they
    can't even do this, since they need uinput for just being able to type
    things on the console...)

    > Please realize that the method of loading a module based on the device
    > node number is very restrictive, and only works for a small minority of
    > drivers.

    Agreed. But here, what is best? To explicitely load a "uinput" module or
    to explicitely open "/dev/input/uinput" ?

    > > The same situation holds for other virtual devices (loop, snd-seq-dummy,
    > > ...).
    >
    > Yes, look at how the distros do this today for loop, they merely load it
    > at boot time and everyone's happy.

    So distributions should load every possible virtual device?

    In the debian case, it doesn't, but udev has a links.conf script that
    creates a /dev/loop/0 entry, which losetup can open when looking for
    loop block devices, and hence the loop module gets auto-loaded. This is
    the behavior I'd expect.

    > And this whole thing has nothing to do with devfs, as you stated above
    > :)

    Ok, but devfs had let me some hope that it would work, and udev doesn't
    so much (the abovementioned links.conf file is considered hacky).

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

    \
     
     \ /
      Last update: 2006-06-19 01:38    [W:0.024 / U:29.424 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site