public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Daniel Pittman <daniel@rimspace.net>
Cc: Jeremy Katz <katzj@redhat.com>, Theodore Tso <tytso@mit.edu>,
	initramfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Dracut -- Cross distribution initramfs infrastructure
Date: Sat, 20 Dec 2008 13:22:54 -0500	[thread overview]
Message-ID: <20081220182254.GA2996@redhat.com> (raw)
In-Reply-To: <87skojrm5e.fsf@rimspace.net>

On Sun, Dec 21, 2008 at 12:50:21AM +1100, Daniel Pittman wrote:

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

There's another reason this is really useful.
If something goes wrong, remotely debugging a users initrd right is
a lot easier if you know what it looks like.  Right now, in Fedora for eg,
where we generate an initrd for each users system at runtime, we need
to get a copy of the generated initrd, and pull it apart just to find
out what modules ended up in there, what didn't, and then somehow
try to work backwards to try and figure out how the generator got into
that state.  After doing this for five years, let me tell you it's
_really_ _really_ painful.

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

At least in theory, with a kernel-event/udev driven system, the additional
modules shouldn't cause any additional boot time. There wouldn't be
events generated to cause them to be loaded, so they'd just be taking
up space.  And the additional load time for a bigger initrd should be
really lost in the noise of the overall boot.

	Dave

-- 
http://www.codemonkey.org.uk

  reply	other threads:[~2008-12-20 18:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-17 18:54 Dracut -- Cross distribution initramfs infrastructure Jeremy Katz
2008-12-17 19:07 ` Christoph Hellwig
2008-12-18  7:36   ` Hannes Reinecke
2008-12-19  7:41     ` Seewer Philippe
2008-12-19  8:18       ` Bernhard Walle
2008-12-19 13:55         ` Hannes Reinecke
2008-12-19 15:27           ` Theodore Tso
2008-12-19 16:56             ` Jeremy Katz
2008-12-20 13:50               ` Daniel Pittman
2008-12-20 18:22                 ` Dave Jones [this message]
2009-01-07 16:04                   ` Hannes Reinecke
2008-12-17 19:31 ` Neil Horman
2008-12-18  9:27   ` Loïc Grenié

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081220182254.GA2996@redhat.com \
    --to=davej@redhat.com \
    --cc=daniel@rimspace.net \
    --cc=initramfs@vger.kernel.org \
    --cc=katzj@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox