Messages in this thread | | | From | Daniel Pittman <> | Subject | Re: Dracut -- Cross distribution initramfs infrastructure | Date | Sun, 21 Dec 2008 00:50:21 +1100 |
| |
Jeremy Katz <katzj@redhat.com> writes: > On Dec 19, 2008, at 10:27 AM, Theodore Tso wrote: >> On Fri, Dec 19, 2008 at 02:55:26PM +0100, Hannes Reinecke wrote: >>> >>> The goal of the initrd is to activate and mount the root fs. >>> And the root fs _only_. Every other system should be configured >>> once the main system is running.
[...]
>> There may also be times when it is useful to operate on the root >> filesystem in some way before it is mounted; in most cases the >> operation can bedone on a filesystem mounted read-only, yes --- but at >> the cost of needing to reboot afterwards if the root filesystem needs >> to be modified by said userspace tool. > > I think that once you start getting into this realm, though, you end > up with an incredibly over-complicated and slow initramfs. If we > instead focus on keeping things "fast", the reboot afterwards isn't > that costly.
One of the features of the Debian / Ubuntu initramfs infrastructure, which sounds remarkably like your design (or vice-versa), is that it drops all the "standard" drivers into the initramfs.
This is, to me, worth several minutes of additional boot time, in terms of flexibility: being able to modify the hardware and be confident that the appropriate drivers are in place already makes life much, much easier.
(In practice I doubt this adds more than a second or five to boot time; certainly, it takes no longer to get to rootfs mounted than the RHEL 4 systems that have nothing but what is essential in the initrd...)
So, it would certainly be my hope — with my systems administration hat on — that your proposed system would support that similar operation as an option, at least.
Personally, I think it makes the right default: better correct than fast, but obviously tastes vary there.
Regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |