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