[lkml]   [2003]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: udev and devfs - The final word
    On Wed, Dec 31, 2003 at 05:20:18PM -0500, Rob Love wrote:
    > On Wed, 2003-12-31 at 17:01, Nathan Conrad wrote:
    > > One thing that I'm confused about with respect to device files is how
    > > kernel arguments are supposed to work. Now, we _seem_ to have a
    > > mish-mash of different ways to tell the kernel which device to open as
    > > a console, which device to use as a suspend device, etc.... Now, all
    > > of the device names are being migrated to userland. How is the kernel
    > > supposed to determine which device to use when it is told use
    > > /dev/hda3 or /dev/ide/host0/something/part3 as the suspend partition?
    > > The kernel no longer knows to which device this string this device is
    > > connected.
    > Uh, Unix systems (Linux included) do not use the filename of the device
    > node at all. Those are just names for you, the user.
    > The kernel uses the device number to understand what device user-space
    > is trying to access. The kernel associates the device with a device
    > number. Normally that number is static, and known a priori, so we just
    > create a huge /dev directory with all possible devices and their
    > assigned numbers (you can see these numbers with ls -la).
    > But if the kernel _tells_ user-space what the device number is, for each
    > device as it is created, we do not need a static /dev directory. We can
    > assemble the directory on the fly and device numbers really no longer
    > matter. This is what udev does.

    I think you've missed a point here. There are several places where kernel
    deals with device identification.
    a) when normal pathname lookup results in a device node on filesystem.
    That's the regular way.
    b) when we create a new device node; device number is passed to
    ->mknod() and new device node is created. Also a normal codepath.
    c) when late-boot code mounts the final root. It used to be black
    magic, but these days it's done by regular syscalls. Namely, we parse the
    "device name" (most of the work is done by lookups in sysfs), do mknod(2)
    and mount(2). It's still done from the kernel mode, but it could be moved
    to userland. Should be, actually.
    d) when kernel deals with resume/suspend stuff. Currently - black
    magic. Should be moved to early userland (same parser as for final root
    name + mknod on rootfs + open() to get the device in question).
    e) in several pathological syscalls we pass device number to
    identify a device. ustat(2) and its ilk - bad API that can't die.
    f) /dev/raw passes device number to bind raw device to block device.
    Bad API; we probably ought to replace it with saner one at some point.
    g) RAID setup - mix of both pathologies; should be done in userland
    and interfaces are in bad need of cleanup.
    h) nfsd uses device number as a substitute for export ID if said
    ID is not given explicitly. That, BTW, is a big problem for crackpipe
    dreams about random device numbers - export ID _must_ be stable across
    i) mtdblk parses "device name" on boot; should be take to early
    userland, same as RAID

    Eventually name_to_dev_t() should be gone from kernel mode
    completely - all callers should be shifted to early userland. But
    that will take a lot of work - currently we have a big mess in that
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:59    [W:0.026 / U:0.032 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site