linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts
@ 2005-02-17 20:06 Erik van Konijnenburg
  2005-02-17 21:50 ` Jeff Garzik
                   ` (10 more replies)
  0 siblings, 11 replies; 12+ messages in thread
From: Erik van Konijnenburg @ 2005-02-17 20:06 UTC (permalink / raw)
  To: linux-hotplug-devel, linux-kernel


OK, time to stop polishing and start publishing.

This is to announce yaird, Yet Another mkInitRD, a rewrite of mkinitrd
based on hotplug algorithms.

MOTIVATION
=====
Why a rewrite?  The versions of mkinitrd that I studied, Debian sid
and Fedora FC3, have some problems: they capture a lot of knowledge
about the boot process, but don't always understand when a new kernel
uses a different module name than the old kernel, may rely on modules
compiled into the kernel, and don't always catch errors at the earliest
opportunity.

Assumption: there are three issues that cause most of these problems.
 - Backward compatibility: sysfs provides a wealth of information
   about hardware, but if you have to support 2.4 kernels, you have
   to limit yourself in the use you can make of that information.
 - Originality: hotplug does a pretty good job of finding the appropriate
   modules for a device, basically because it closely follows the
   algorithms the kernel uses for matching hardware with modules.
   Deviating from those algorithms is unlikely to produce a more
   robust result.
 - Shell scripting: beyond a certain level of complexity, the shell
   syntax makes it difficult to focus on the data structures you're
   trying to process and makes it difficult to do rigorous error checking.

Yaird is intended to find out whether that assumption is correct: if so, 
a program to build initrd images will be more reliable if it's written
in perl, if it uses sysfs to determine what hardware needs to be supported,
and if it closely follows the methods hotplug uses find the modules
needed to support some hardware.

STATUS
===
There is working code: yaird booted the machine this note is written on.
Code is available online, there also is a paper that discusses the workings
of the application in detail.

	http://www.xs4all.nl/~ekonijn/yaird/

So far, the program works correctly on every machine it's been tested on,
but with only two test boxes that does not mean much.

Basic creature comforts are in place: "configure; make" but no RPM or
deb files, a README and help option but no manual page.

Features:
 - understands SATA and IDE.  USB sticks and SCSI should work, but are
   untested.
 - understands MDADM and LVM2, activates only necessary devices,
   understands stacks like LVM on top of stripe on top of mirror.
 - handles both initrd and initramfs.
 - understands USB keyboards.
 - understands hotplug blacklist.
 - knows that a module compiled into the kernel does not need insmod.
 - understands /etc/fstab, including niceties such as labels, uuids and
   octal escapes.
 - image generation understands symbolic links and shared libraries.
   (should support 32bit emulation on 64bit kernels; untested).
 - templating system to simplify tuning the initrd image to the distribution.
 - avoids hard-coded device numbers; does not require devfs.
 - testing mode gives detailed overview of the systems hardware
   and the modules needed to support that.

There are rough edges in practically every feature: this is suitable
for testing, but not for production use.

TODO
==
(1) Testing so far is 100% successful, but with just two boxes to play
with, that's not saying much.  If you can find space to test the code
on your system, your results are highly appreciated.  At this point,
hardware testing is most valuable: I already know that dm-crypt is
unsupported for now, but whether this stuff can boot a powerbook, sparc,
or just about anything else is an open question.

(2) Feedback.  This may be an interesting idea, but how does it relate
to other new stuff floating about?  In particular, what about the work
that's going on putting udev on initramfs: are these approaches complementary
or alternatives?  Different perspectives on where this stuff fits in would
help.

(3) Support more configurations.  dm-crypt is unsupported for now, and so
are multipath, swsusp, EVMS, NFS and loopback mounts.  Implementing this
stuff becomes interesting once there are some tests results that the
basic ideas work in practice.

Regards,
Erik




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click
_______________________________________________
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

^ permalink raw reply	[flat|nested] 12+ messages in thread
end of thread, other threads:[~2005-03-17  8:26 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-02-17 20:06 [ANNOUNCE] yaird, a mkinitrd based on hotplug concepts Erik van Konijnenburg
2005-02-17 21:50 ` Jeff Garzik
2005-02-17 22:50 ` Roman Kagan
2005-02-19  2:00 ` Erik van Konijnenburg
2005-02-22 11:51 ` Roman Kagan
2005-02-22 17:48 ` Harald Hoyer
2005-02-22 19:26 ` Patrick Mansfield
2005-02-22 20:03 ` Roman Kagan
2005-02-22 21:25 ` Erik van Konijnenburg
2005-02-22 21:48 ` Erik van Konijnenburg
2005-02-22 22:57 ` Erik van Konijnenburg
2005-03-17  8:26 ` Werner Almesberger

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).