[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110828214225.GA8987@openwall.com>
Date: Mon, 29 Aug 2011 01:42:25 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: Re: initrd/udev in Owl?
Vasiliy,
On Sun, Aug 28, 2011 at 01:40:28PM +0400, Vasiliy Kulikov wrote:
> Another way to delay syslinux integration is using initrd and
> compilation most of drivers as modules.
No, this won't help us avoid the floppy image size limit at all. We'll
need to have the exact same set of drivers in the floppy image anyway -
only moving them from the kernel image and into the initrd image. This
may or may not be a desirable change to make, but it's irrelevant to the
size issue (well, it may result in a slight size increase for
kernel+initrd image combined) - so is to be discussed separately from
the floppy image size issue.
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.
> However, then we need some
> mechanism to automatically load appropriate kernel modules - udev.
Now this may in fact help with the size issue. In our kernels, we have
disk controller and NIC drivers compiled in. The former have to be
there (or in initrd, which is also part of the floppy image anyway),
whereas the latter we can move to modules. The only thing that's
stopping us from doing the latter is that it affects usability - it is
useful for NICs to be detected right after CD boot, especially when we
have to provide instructions to someone not very familiar with Linux on
CD-booting a server for us to access remotely (such as for us to install
Owl remotely, which we sometimes do).
So I am willing to consider ways to have NIC drivers in modules and have
the proper ones of them auto-loaded on boot.
While I like having mkinitrd in Owl for easy installation of third-party
kernel packages, I dislike the mkinitrd approach for our own kernels.
I dislike being forced to use machine-specific initrd images. And I
think the NIC drivers are better to have outside of the initrd image
anyway. So we might want to invent something else here (or see what
existing alternatives there are).
> Why don't we have udev in Owl? Is there any strong reasons to avoid it
> soever?
Initially, it was for historical reasons - Owl predates udev.
Then this topic was brought up on our not-yet-public development list a
few years ago. IIRC, at the time mjt suggested that udev was somewhat
likely to be replaced with something else in a few years (which would be
now). We could want to ask for his opinion now.
> 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),
Lacking full control by admin is really nasty/unacceptable - we'd need
to provide some easy/supported way to regain such control.
> except (2).
Yes, (2) is serious (I trust your description of it; I am not familiar
with this myself).
> However, I'd
> want to know whether udev absence is a deliberate step or just a miss.
As I tried to explain above, it's a mix of both.
Thank you for the summary - it's very useful.
Alexander
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.
