[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4E5B79E2.50708@msgid.tls.msk.ru>
Date: Mon, 29 Aug 2011 15:37:06 +0400
From: Michael Tokarev <mjt@....msk.ru>
To: owl-dev@...ts.openwall.com
Subject: Re: initrd/udev in Owl?
On 29.08.2011 14:48, Vasiliy Kulikov wrote:
> Solar,
>
> On Mon, Aug 29, 2011 at 01:42 +0400, Solar Designer wrote:
>> What I think we more obviously want is mkinitrd - such that people can
>> easily install OpenVZ, Red Hat, or CentOS kernel RPMs on Owl if they
>> choose to use or test those kernels (e.g., to quickly determine if a
>> certain hardware compatibility issue is Owl-specific or not). Once we
>> have mkinitrd in Owl, we can revisit the topic of possibly using initrd
>> in our own kernel builds.
>
> I'm afraid these kernels have a stong need in udev as they have almost
> everything as modules (not only device drivers).
There's really nothing in udev that is not available elsewhere.
For example, there is not need to pull for some events - kernel runs
/sbin/hotplug on every event still (unless disabled by udev), and that
script can be just 3-line shell script to autoload modules -- if we
only talk about driver loading. Udev does not load modules, it merely
executes modprobe if it sees modalias attribute, and that attribute is
taken from sysfs anyway.
Udev has some helpers to maintain other things, one of them is to maintain
/dev/disk/* symlinks (mentioned in another email). Again, thses helpers
can be and are implemented separately - in libblkid too.
That to say: there are other way to react to kernel events and manage
dynamic system, including autoloading modules and managing /dev/disk/
symlinks. Udev is the most convinient one, with lots of rules already
provided for it.
Its original main role - managin /dev/ nodes - is not really necessary
anymore with introduction of devtmpfs. What left there is managing of
permissions (since devtmpfs provides all nodes owned by root:root with
0600 -- iirc -- permissions). For this task, most interesting alternative
may be mdev applet in busybox.
It is relatively easy to run modern system without udev, after solving
two problems: 1) lots of packages on any distribution actually depends
on udev (declared as dependent in package metadata) so it is difficult
to keep udev out of the system, and 2) quite some work is needed to
provide "rules" for an alternative implementation (be it some home-
grown utility/daemon or just a shell script) - since most packages
comes with udev rules from upstream already, and for non-udev system
you have to create them manually.
On a bright side, udev is quite dumb and small and does not do many
things itself, everything is done from rules files, including module
autoloading and gathering filesystem/etc information for /dev/disk/
symlinks. These rules are easy to review and modify if necessary.
I dislike udev myself, but at this stage it is better to work with
it than to fight with it. IMHO anyway.
/mjt
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
