Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sun, 28 Aug 2011 13:40:28 +0400
From: Vasiliy Kulikov <>
Subject: initrd/udev in Owl?


Another way to delay syslinux integration is using initrd and
compilation most of drivers as modules.  However, then we need some
mechanism to automatically load appropriate kernel modules - udev.

Why don't we have udev in Owl?  Is there any strong reasons to avoid it

udev is the only official way to handle hardware addition from
userspace (except ugly sysfs polling).  It would give us some
significant advantages over the current scheme:

1) As mentioned above, with udev we can compile many drivers as modules,
keeping the base kernel image small.

2) Since ~2.6.27 different hardware buses are scanned in parallel,
asynchroniously.  It means that if you have multiple SATA/USB drives (or
SATA+IDE drives), there is a small probability to get drives with wrong
enumeration.  The same with network adapters.  udev can handle this
regardless of the enum order, properly naming devices.

3.1) If we want to keep current /dev/ structure (keeping nonexisting dev
nodes) to have a visual and obvious permission rules, udev can be
configured to run modprobe only, without creating dev nodes.
(modules autoloading only)

3.2) If we want "modern" scheme with automatic dev nodes creation, we
can save our restricted permission rules - use existing udev rules, but
patch them by trivial 'sed "s/MODE=.../MODE=.../" rules.d/*'.
(autoloading and dev nodes autocreation)

4) udev can be configured to run hw-specific scripts on device addition
(it is in modern distros) like ifup eth0 on eth0 addition, etc.  It can
be very suitable for sysadmin under certain circumstances.

5) as udev automatically loads modules, there is no need to
remember/identify how the appropriate module is called to run "modprobe $MOD"

I don't insist on udev as it also complicates modules loading rules (it
is not fully controlled by an admin anymore), except (2).  However, I'd
want to know whether udev absence is a deliberate step or just a miss.



Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ