[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.372 / U:9.924 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site