With the announcement of udev 018, Greg KH noted that at this time he is running with udev [story] managing the /dev directory on his primary email and development server. He says, "this is a major milestone for udev and it proves that it is a viable solution," going on to add, "udev development isn't done, but for anyone who has not checked it out yet, I suggest you do so."
To make the task of trying udev a little easier, Greg has released a short howto. He says:
"Here's a small document that I've added to the udev tarball that explains how I managed to get udev to manage my /dev tree on a Red Hat Fedora based machine. All you Gentoo developers can just laugh as it's already integrated into your distro."
From: Greg KH [email blocked]
To: linux-hotplug-devel, [email blocked]
Subject: [ANNOUNCE] udev 018 release
Date: Thu, 19 Feb 2004 10:59:32 -0800
I've released the 018 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-018.tar.gz
rpms built against Red Hat FC2-test1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-018-1.i386.rpm
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-018-1.src.rpm
udev allows users to have a dynamic /dev and provides the ability to
have persistent device names. It uses sysfs and /sbin/hotplug and runs
entirely in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG
enabled to run. Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs
Major changes from the 017 version:
- We now handle the ability to generate all partitions for a
device to allow removable devices to work in a sane manner.
This has been requested by a lot of people.
- there's a new %s{} modifier available for people to use
- the SYSFS_ style rule has changed to SYSFS{}. The old style
is still supported for now, but you have been warned
- %c1 style modifiers has been changed to %c{1}. Again, the old
style format still works.
- scsi_id is built by default now in the rpm and is available in
the pre-built rpm package. This should get it a wider range
of testing.
- lots of bug fixes and other cleanups.
In all, there is nothing hugely major in this release, but any current
users of udev will want this version for all of the bugfixes if for
nothing else.
Thanks to everyone who has send me patches for this release, a full list
of everyone, and their changes is below.
udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev
Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.
thanks,
greg k-h
Summary of changes from v017 to v018
============================================
<ext.devoteam.varoqui:sncf.fr>:
o [PATCH] symlink dm-[0-9]* rule
o update extras/multipath
<john-hotplug:fjellstad.org>:
o init.d debian patch
Kay Sievers:
o udev - TODO update
o udev - add %s{filename} to man page
o udev - udevd/udevsend man page
o udev - switch callout part selector to {attribute}
o udev - switch SYSFS_file to SYSFS{file}
o udev - create all partitions of blockdevice
o allow SYSFS{file}
o Adding '%s' format specifier to NAME and SYMLINK
Greg Kroah-Hartman:
o added some scsi_id files to the bk ignore file
o added scsi_id and some more documentation to the udev.spec file
o update udev.rules.gentoo with new config file format
o Update the Gentoo udev.rules and udev.permissions files
o Create a udev.rules.examples file to hold odd udev.rules
o add udevd priority issue to the TODO list
o more HOWTO cleanups
o add HOWTO detailing how to use udev to manage /dev
o mv libsysfs/libsysfs.h to libsysfs/sysfs/libsysfs.h to make it easier to use
o add start_udev init script
o add support for UDEV_NO_SLEEP env variable so Gentoo people will be happy
o start up udevd ourselves in the init script to give it some good priorities
o update the red hat init script to handle nodes that are not present
o add a "old style" SYSFS_attribute test to udev-test.pl
o Have udevsend report more info in debug mode
o Have udevd report it's version in debug mode
o fix up bug created for udevtest in previous partition creation patch
o update the udev.spec to add udevtest and make some more Red Hat suggested changes
o add ability to install udevtest to Makefile
o 017_bk mark
o Add another test to udev-test.pl and fix a bug when only running 1 test
o Fix bug where we did not use the "converted" kernel name if we had no rule
o v017 release TAG: v017
Patrick Mansfield:
o udev use new libsysfs header file location
o udev add some ID tests
From: Greg KH [email blocked]
Subject: Re: [ANNOUNCE] udev 018 release
Date: Thu, 19 Feb 2004 11:13:15 -0800
On Thu, Feb 19, 2004 at 10:59:32AM -0800, Greg KH wrote:
> I've released the 018 version of udev. It can be found at:
> kernel.org/pub/linux/utils/kernel/hotplug/udev-018.tar.gz
As of this release, I've been running with udev managing my /dev for me
exclusively on my main email and development machine. This is a major
milestone for udev and it proves that it is a viable solution.
I'd like to say thanks to everyone who has made this possible to do:
- Pat Mochel for creating sysfs and listening to my crazy ideas
about how we could create a userspace devfs all those years
ago.
- Dan Stekloff for prodding me to actually implement this crazy
idea and who came up with a solid initial design document,
without which this project would have never left the dream
stage.
- Kay Sievers for almost single-handedly taking over the whole
udev TODO list and converting udev from a small "proof of
concept" toy into a powerful and useful tool.
- Pat Mansfield for creating the scsi_id tool and enabling udev
to call external programs, which instantly made udev a real
tool in the fine Unix tradition.
- All of the Gentoo developers who integrated udev into their
distro and showed me that it can actually run a machine.
- everyone who has sent in udev patches, bug reports, and
feature requests. Without these udev would only work for me,
and not the rest of the world. A community is very important.
- the distros for picking up udev without me having to beg :)
- everyone else who I know I've forgotten...
udev development isn't done, but for anyone who has not checked it out
yet, I suggest you do so. I'll post a small HOWTO that shows how to
configure udev to manage your /dev without any problems or legacy issues
(the 2.4 kernel will still work just fine on the same box.)
If anyone has any suggestions for things that are lacking in udev,
please let me and the linux-hotplug-devel mailing list. This especially
goes for any distro developers who are trying to integrate it into their
systems.
thanks again,
greg k-h
From: Greg KH [email blocked]
Subject: HOWTO use udev to manage /dev
Date: Thu, 19 Feb 2004 11:16:36 -0800
Here's a small document that I've added to the udev tarball that
explains how I managed to get udev to manage my /dev tree on a Red Hat
Fedora based machine. All you Gentoo developers can just laugh as it's
already integrated into your distro.
Any users of other distros, feel free to send me updates to this to show
how to do it for yours. Any distro maintainers, feel free to just
integrate udev into your system so this kind of tweaking isn't
necessary :)
thanks,
greg k-
---------------------------------------
HOWTO use udev to manage /dev
This document describes one way to get udev working on a Fedora-development
machine to manage /dev. This procedure may be used to get udev to manage
/dev on other distros, if you modify some of the steps.
This will only work if you use a 2.6 based kernel, preferably the most
recent one. This does not prevent your machine from using a 2.4
kernel, if you boot into one, udev will not run and your old /dev will
be present with no changes needed.
NOTE NOTE NOTE NOTE NOTE NOTE NOTE
This is completely unsupported. Attempting to do this may cause your
machine to be unable to boot properly. USE AT YOUR OWN RISK. Always
have a rescue disk or CD handy to allow you to fix up any errors that
may occur.
NOTE NOTE NOTE NOTE NOTE NOTE NOTE
- Build and install udev as specified in the README that comes with
udev. I recommend using the following build options to get the
smallest possible binaries:
make USE_KLIBC=true USE_LOG=false DEBUG=false
- disable udev from the boot process by running:
chkconfig udev off
or
chkconfig --del udev
as root.
- place the start_udev script somewhere that is accessible by your
initscripts. I placed it into /etc/rc.d with the following command:
copy extras/start_udev /etc/rc.d/
- modify the rc.sysinit script to call the start_udev script as one of
the first things that it does, but after /proc and /sys are mounted.
I did this with the latest Fedora startup scripts with the patch at
the end of this file.
- make sure the /etc/udev/udev.conf file lists the udev_root as /dev.
It should contain the following line in order to work properly.
udev_root="/dev/"
- reboot into a 2.6 kernel and watch udev create all of the initial
device nodes in /dev
If anyone has any problems with this, please let me, and the
linux-hotplug-devel@lists.sourceforge.net mailing list know.
A big thanks go out to the Gentoo developers for showing me that this is
possible to do.
Greg Kroah-Hartman
<greg@kroah.com>
----------------------------------
Patch to modify rc.sysinit to call udev at the beginning of the boot
process:
--- /etc/rc.sysinit.orig 2004-02-17 11:45:17.000000000 -0800
+++ /etc/rc.sysinit 2004-02-17 13:28:33.000000000 -0800
@@ -32,6 +32,9 @@
. /etc/init.d/functions
+# start udev to populate /dev
+/etc/rc.d/start_udev
+
if [ "$HOSTTYPE" != "s390" -a "$HOSTTYPE" != "s390x" ]; then
last=0
for i in `LC_ALL=C grep '^[0-9].*respawn:/sbin/mingetty' /etc/inittab | sed 's/^.* tty\([0-9][0-9]*\).*/\1/g'`; do
Empty /dev
This may be kind of a dumb question, but does this little howto allow the fabled 'boot up with an empty /dev and I'll automagically populate it' thing?
I saw some mention of initramfs and early userspace in various usenet posts that I googled through, but no mention on how to actually pull this off.
RE: empty /dev
I believe that it will work with empty /dev
but I didn't test it.
I needed to have at least /de
I needed to have at least /dev/console and /dev/null available or else the kernel gave me an error (something about unable to open a console) and wouldnt boot.
udev still inferior to devfs?
If this is true, udev still lacks some of devfs' capabilities. In our nfs-root+devfs setup, the root filesystem is mounted with nodev flag. Opening devices results in error.
Actually this /dev/console crap results from sysvinit IMHO needlessly insisting on switching kernel-inherited stdout file descriptor to freshly opened /dev/console one. More robust solution would be to survive without any /dev nodes. If you look at linux/init/main.c, the kernel stdout is really opened from /dev/console. Maybe some old systems needed this in the fabulous 90's.
well it stopped the kernel fr
well it stopped the kernel from booting before it started init so its not really udev's fault since udev has to be started after init (being a userspace thing and all...)
Inferior? Different.
Correct, udev lacks some of devfs' capabilities. This is natural; udev is a userspace program, devfs is an in-kernel filesystem. udev will never allow for the "try to open a device node file, if it doesn't exist, create it appropriately" action, for example. (It's kind of messy to begin with; should you allow both /dev/tty/0 and /dev/tty0 and (some other naming scheme)? If not, which one should you allow? How can you let the user configure this at runtime for every device? If you want to store this data across boots, where does it go? Remember, kernel doesn't know about files and whatnot, and allocating an entire partition for this sort of data seems overkill. udev, on the other hand, keeps its device cache under /var on my system.)
The point of udev is to allow the user to enforce a consistent naming scheme for all devices in the system all the time; i.e., my black USB card reader will always be /dev/sda1, even if I have another card reader plugged in first. The whole dynamic device nodes thing is just a perk.
you can boot with an empty dev
/dev/console only lets you see the output of init scripts ... you can still boot and get to the *getty's without it
if your computer doesnt boot without /dev/null then that's a short coming of the init scripts, maybe you should yell at your distro for it :P
Question (bug in udev?)
Got a bit of a weird problem here. I have udev-016 (which I'm upgrading to 018 as I type this, but I figured I'd ask anyway) - does /dev/input/mice work for anyone with udev? Because mine seems to be broken. I'm pretty sure that it works ok in the kernel itself, but when I have the node created on a udev system the kernel tells me "No such file or device" even though I have entries for /dev/input/mouse{0,1}.
Any thoughts?
Mouse on udev
I use gentoo and my ps/2 mouse is labelled as /dev/psaux which is linked to /dev/misc/psaux
I can't remember which dev entry my old psaux config pointed to, but I definetly had to change the config when I moved over to udev.
udev and mice
Hrm. I have a Logitech USB keyboard which has a virtual mouse in it - the scrollwheel sends ZAxisMapped events, and I also have a regular USB optical mouse, so they show up as (respectively) mouse0 and mouse1. However, the neat thing is that udev-018 has solved this for me so things are working properly now - if anybody else had this problem, I'd recommend picking up the new release.
Ya, my usb scanner (Microtek
Ya, my usb scanner (Microtek V6UPL) is seen as a usbcam, earlier it was a disk. But it still works.
udev.permissions?
udev doesn't set the groups i defined for devices in udev.permissions anymore, it still sets the permissions set in there. udevinfo reports the correct group, but for some reason udev doesn't change owner/group.
Worked fine with 014, but not anymore since the upgrade to 018.
Anyone got an idea what could be wrong there?
Works for me :) Are you bu
Works for me :)
Are you building udev against glibc or klibc?
Post this kind of question to the linux-hotplug-devel mailing list, otherwise no one knows to look into the issue.
greg k-h
It was built against klibc, i
It was built against klibc, i just switched to glibc and now it works :)
framebuffer
Got udev working as well, however, it is not creating my framebuffer devices.
Odd though, bootsplash and links -g works. Just rapidly complains about:
open /dev/fb/0 and /dev/fb0: No such file or directoryAnybody getting the same thing?
not yet
Framebuffer deviced are not yet properly sysfs'ified. Patches are coming, though, but last one was pulled before releasing of 2.6.3 because it was incomplete.
IMO you should expect /dev/fb/* with 2.6.4.
--
:wq
Yeah the exact same
Let me know if you solved this would ya. Thanks.. I am considering installing gentoo
I have a /udev/fb0 with 2.6.9
I have a /udev/fb0 with 2.6.9, so it seems it's fixed.
DVB-sysfs
I tried to write automatic detection of DVB cards using sysfs in a program, and was lost. Does udev handle DVB devices correctly?
Don't know, does dvb devices
Don't know, does dvb devices use sysfs correctly?
And why are people posting questions here and not where people will
actually see them? Like on the linux-hotplug-devel mailing list?
greg k-h