On Tue, Mar 23, 2004 at 10:18:59PM -0800, Paul Johnson wrote:
| "Derrick 'dman' Hudson" <dman@dman13.dyndns.org> writes:
|
| > The thing with udev is it is all userspace, therefore it works with
| > any 2.6 kernel (that has SYSFS in it). You can upgrade udev without
| > touching your kernel, unlike devfs. I've been using udev for a few
| > weeks now (since 0.18 arrived in "experimental") and I haven't had
| > any major problems (only a hurdle or two).
|
| OK. So how does it work? You've got my interest piqued. Does it
| work kinda like devfs, or does it maintain the devices nodes on disk?
Have you booted with a 2.6 kernel yet? If so, take a look in /sys.
In there you'll see all kinds of detailed information about every bus
and device in your system. (well, not quite every - only those whose
drivers have been updated to report their existance via sysfs)
Install the 'udev' package. The initscript starts udevd - a userspace
daemon. The way the debian-packaged udev works is it moves/copies the
exist /dev to /etc/udev/.dev. Then it mounts a ramfs file system on
/dev and creates nodes for everything that was in the existing /dev
before the new ramfs was mounted over it. Whenever a new device is
found, the kernel runs the userspace /sbin/hotplug program. Through
some chain of events (I have never looked at the inner workings of
hotplug) udevd is told that a new device is present. udevd queries
the properties of the device by reading files in /sys and creates the
appropriate nodes and links in /dev based on the config files in
/etc/udev.
So, to summarize :
. udev is dynamaic management of /dev along the lines of devfs
. udev is purely userspace (no kernel module or driver)
. therefore the naming scheme is defined purely in userspace,
not in the kernel
You could, if you wanted, have udev manage a disk-backed /dev
filesystem or any other file system, but the debian pacakge defaults
to using a new ramfs for each boot. (which is fine by me)
As a side-effect of udev copying the existing nodes to the new ramfs
filesystem, your new /dev will be just as cluttered unless you clean
out the static /dev first. My recommendation (what I have done) is:
. boot with an installer cd or other media
. # cd / ; mv dev _static_dev
. # mkdir dev ; cd dev
. # mknod console c 5 1 ; chgrp tty console ; chmod 600 console
(the kernel needs /dev/console to exist or you'll get
a panic during boot up)
. # mknod null c 1 3 ; chmod 666 null
. # mknod zero c 1 5 ; chmod 666 zero
(I don't know if these are needed for boot or not, but
they are always needed on a running system and it
doesn't hurt to create them at this point)
. reboot
Note that if you use vesafb and X uses the fbdev driver, then you'll
have a little snag starting X. I think vesafb just doesn't present
itself through sysfs, but I could be wrong. At any rate, put the line
M fb0 c 29 0
in /etc/udev/links.conf and udev will always create /dev/fb0 for you.
Then X will be able to start, using the fbdev driver.
-D
--
One man gives freely, yet gains even more;
another withholds unduly, but comes to poverty.
Proverbs 11:24
www: http://dman13.dyndns.org/~dman/ jabber: dman@dman13.dyndns.org
Attachment:
signature.asc
Description: Digital signature