From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: recent changes to udev
Date: Tue, 08 Nov 2005 18:43:08 +0000 [thread overview]
Message-ID: <20051108184308.GB7254@vrfy.org> (raw)
udev 074 is released and should be a big step in improving
boot time and unifying the device initialization at system
startup. During the last year we sucked almost all old
hotplug stuff into udev and made udev a generic device
event manager. We have almost arrived, time to do give you
all an update and request some housekeeping...
With udev 072 the parsing of the configured rules has moved
into the damon. For every event process, udevd just clones
itself, has the rules already in memory, processes the event
and exits. No initialization or exec()'ing the udev binary
happens anymore.
Kernel 2.6.15 will have a new input layer with integrates
proper with the driver core. This will make it possible to
feed udev by netlink only. We already use netlink for a
while now and discard the /sbin/hotplug messages. udev 074
depends entirely on netlink and will not work without it.
For older kernels udevsend can still pass the "input"
events to udevd.
With kernel 2.6.15 on, /proc/sys/kernel/hotplug can be
disbled completely (I can't really believe, that this
finally happens :)).
After all the experiments with udev and "coldplug", it seems
we found a nice way to do it now. On SUSE we started with
storing the events from initramfs and replaying them after
the real root is active. This was working well, but reqired
a tricky initramfs setup and was not working with custom
kernels.
Then we started "udevsynthesize" to read all information
from sysfs, reconstruct the environment and pass the event
to the udevd daemon to look like a real event.
At one point, trying to fake the environment to look like
a real event was so silly, that I just added a "uevent" file
to every kobject directory in /sys, which sends the netlink
message again to udevd...
That way, the whole coldplug is about 40 lines of shell
script in the udev boot script on SUSE now. It just writes to
every "uevent" file it finds, which will trigger the event to
load modules, setup the device and create the device node
at boot time. This script needs some improvement, but works
nice for a first cut.
We have only a single codepath, all coldplug events trigger
exactly the same rules and logic as it would happen for a
real event at device initialization.
I'm writing this to encourage you guys to work on an, as far
as possible, unified layout and way to integrate udev and
device init across distributions. In the end it may be possible
some day to share a basic set of rules, and distros just add
specific parts in their own files.
In the experimental SUSE version, I have currently the
following layout on top of the usual installation places
defined in the Makefile:
/lib/udev/
Directory to place all scripts and binaries used by udev
rules, but not useful on the commandline. Some distros have
/etc/udev/sripts/, which can't contain binaries which limits
the use of this directory too much. Stuff like scsi_id or
vol_id are still in /sbin cause they may be useful on the
commandline, but that could be discussed.
/lib/udev/devices/
Real device nodes! Created with mknod, with the proper
permissions and ownership set. A bunch of symlinks and
nodes as a workaround for virtual devices or "broken"
kernel drivers. The whole content of this directory will
be copied over to the tmpfs mounted /dev at every boot
time.
If the user or a package has the need for a static node,
just place it there and it will be in /dev forever.
The reason for real nodes instead of a config file is that
using the "natural" interface to device nodes like mknod
chown, chmod is much easier to use than to invent another
file format. Also extendend attributes and ACL's may work
that way.
The current SUSE rpm can be found here, or at one of the mirrors:
ftp://ftp4.gwdg.de/pub/opensuse/distribution/SL-OSS-edge/inst-source/suse/src
And again: Please get rid of: /etc/dev.d/ and /etc/hotplug.d/
users, everything should be converted to udev rules. The next
SUSE release will not have any of the old hotplug stuff, also
the /sbin/hotplug program and /etc/hotplug/* does not even exist
on the system.
Many thanks to Marco d'Itri. We worked a lot together recently
to get the new coldplug running and it is also in Debian unstable
for the last few weeks. When 2.6.15 is out, it should be very easy
to switch from the currently used udevsynthesize to the kernel
"uevent" trigger.
Thanks,
Kay
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next reply other threads:[~2005-11-08 18:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-08 18:43 Kay Sievers [this message]
2005-11-09 13:31 ` recent changes to udev Dennis Veatch
2005-11-09 17:11 ` Kay Sievers
2005-11-09 17:41 ` Dennis Veatch
2005-11-10 1:39 ` Scott James Remnant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051108184308.GB7254@vrfy.org \
--to=kay.sievers@vrfy.org \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).