[PATCH 50/50] Some documentation updates
parent
53f954561a
commit
c968efbb13
1
HACKING
1
HACKING
|
|
@ -18,5 +18,4 @@ and set
|
|||
|
||||
Requirements:
|
||||
* udev
|
||||
* plymouth > 0.6.0-2 (for encrypted root; otherwise, it should noop out)
|
||||
* nash (for switchroot until we get in util-linux)
|
||||
|
|
|
|||
19
README
19
README
|
|
@ -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
|
||||
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
|
||||
possible. Every distribution has their own tool here and it's not
|
||||
something which is really interesting to have separate across them.
|
||||
|
|
|
|||
11
TODO
11
TODO
|
|
@ -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
|
||||
ones
|
||||
* 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
|
||||
for us appropriately
|
||||
* Support thaw (resume from hibernate)
|
||||
* Proving some support with a simple network based root would be good
|
||||
* 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
|
||||
|
|
@ -40,3 +33,7 @@ GENERATOR TODO
|
|||
--------------
|
||||
* Default module specificatoin could use some work
|
||||
* 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.
|
||||
|
|
|
|||
Loading…
Reference in New Issue