[PATCH 50/50] Some documentation updates

master
Victor Lowther 2009-02-13 04:43:31 -08:00 committed by Dave Jones
parent 53f954561a
commit c968efbb13
3 changed files with 23 additions and 8 deletions

View File

@ -18,5 +18,4 @@ and set


Requirements: Requirements:
* udev * udev
* plymouth > 0.6.0-2 (for encrypted root; otherwise, it should noop out)
* nash (for switchroot until we get in util-linux) * nash (for switchroot until we get in util-linux)

19
README
View File

@ -19,6 +19,25 @@ we'll grow some hooks for running arbitrary commands in the flow of
the script, but it's worth trying to resist the urge as much as we can the script, but it's worth trying to resist the urge as much as we can
as hooks are guaranteed to be the path to slow-down. as hooks are guaranteed to be the path to slow-down.


Most of the initrd generation functionality in dracut is provided by a bunch
of generator modules that are sourced by the main dracut script to install
specific functionality into the initrd. They live in the modules subdirectory,
and use functionality provided by dracut-functions to do their work.
Some general rules for writing modules:
* Use one of the inst family of functions to actually install files
on to the initrd. They handle mangling the pathnames and (for binaries,
scripts, and kernel modules) installing dependencies as appropriate so
you do not have to.
* Scripts that end up on the initrd should be POSIX compliant. dracut
will try to use /bin/dash as /bin/sh for the initrd if it is available,
so you should install it on your system -- dash aims for strict POSIX
compliance to the extent possible.
* Hooks MUST be POSIX compliant -- they are sourced by the init script,
and having a bashism break your user's ability to boot really sucks.
* Generator modules should have a two digit numeric prefix -- they run in
ascending sort order. Anything in the 90-99 range is stuff that dracut
relies on, so try not to break those hooks.

Also, there is an attempt to keep things as distribution-agnostic as Also, there is an attempt to keep things as distribution-agnostic as
possible. Every distribution has their own tool here and it's not possible. Every distribution has their own tool here and it's not
something which is really interesting to have separate across them. something which is really interesting to have separate across them.

11
TODO
View File

@ -16,15 +16,8 @@ the rules that we care about in the initramfs. These could be
symlinks/hardlinks to the main rules in some cases or special-cased symlinks/hardlinks to the main rules in some cases or special-cased
ones ones
* LVM activation by udev is a bit of a large hammer right now * LVM activation by udev is a bit of a large hammer right now
* dm-crypt (luks) depends on plymouth
* plymouth is hard-coded... this may be reasonable as modesetting goes
into the upstream kernel as a way to get off of fb-splash stuff, but I
can see this being a point of contention for other distros
* plymouth --show-splash should be done as a udev rule so that we
can switch modes first
* root= parsing should be done with udev creating /dev/root symlink * root= parsing should be done with udev creating /dev/root symlink
for us appropriately for us appropriately
* Support thaw (resume from hibernate)
* Proving some support with a simple network based root would be good * Proving some support with a simple network based root would be good
* Do we just call dhclient, etc or try to get NetworkManager going? * Do we just call dhclient, etc or try to get NetworkManager going?
* Would be nice not to have to kill and restart udev across switchroot * Would be nice not to have to kill and restart udev across switchroot
@ -40,3 +33,7 @@ GENERATOR TODO
-------------- --------------
* Default module specificatoin could use some work * Default module specificatoin could use some work
* udev rule copying, as mentioned above, is a bit too hard-coded * udev rule copying, as mentioned above, is a bit too hard-coded
* pkg-config integration, to make it easy for other packages to use us.
* Autotool-izing the package is probably overkill, but making the Makefile
vaguely autotools-compatible and adding a configure script would probably
be a good thing.