mkinitrd unification across distributions
 help / color / mirror / Atom feed
From: Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Daniel Pittman <daniel-zvVxMF7wGoXk1uMJSBkQmQ@public.gmane.org>
Cc: Jeremy Katz <katzj-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Theodore Tso <tytso-3s7WtUTddSA@public.gmane.org>,
	initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.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-zvVxMF7wGoXk1uMJSBkQmQ@public.gmane.org>

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
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1229540094.28858.150.camel@aglarond.local>
     [not found] ` <1229540094.28858.150.camel-T9xAYgMuJli44ywRPIzf9A@public.gmane.org>
2008-12-17 19:07   ` Dracut -- Cross distribution initramfs infrastructure Christoph Hellwig
2008-12-17 19:31   ` Neil Horman
     [not found] ` <20081217190700.GA15377@infradead.org>
     [not found]   ` <20081217190700.GA15377-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2008-12-18  7:36     ` Hannes Reinecke
     [not found]   ` <4949FD67.6040906@suse.de>
     [not found]     ` <4949FD67.6040906-l3A5Bk7waGM@public.gmane.org>
2008-12-18 20:12       ` Jeremy Katz
     [not found]         ` <1229631131.13174.23.camel-T9xAYgMuJli44ywRPIzf9A@public.gmane.org>
2008-12-19  8:21           ` Hannes Reinecke
     [not found]             ` <494B5979.3080606-l3A5Bk7waGM@public.gmane.org>
2008-12-19 17:08               ` Jeremy Katz
     [not found]                 ` <44C50A6A-0FDB-4BF0-8B8B-CD9DAC7B7ED4-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-12-19 20:05                   ` Seewer Philippe
     [not found]                     ` <494BFE7E.8090301-omB+W0Dpw2o@public.gmane.org>
2008-12-19 20:41                       ` Jeremy Katz
2008-12-23 11:32                       ` Till Maas
2009-01-07 16:14                   ` Hannes Reinecke
2008-12-19  7:41       ` Seewer Philippe
     [not found]         ` <494B5031.5080306-omB+W0Dpw2o@public.gmane.org>
2008-12-19  8:18           ` Bernhard Walle
     [not found]             ` <20081219091841.207bc951-Hxm9IJOWyO+kWa+peg0mPg@public.gmane.org>
2008-12-19 13:55               ` Hannes Reinecke
     [not found]                 ` <494BA7CE.2020007-l3A5Bk7waGM@public.gmane.org>
2008-12-19 15:27                   ` Theodore Tso
     [not found]                     ` <20081219152708.GE9871-3s7WtUTddSA@public.gmane.org>
2008-12-19 16:56                       ` Jeremy Katz
     [not found]                         ` <9C4F1B7D-CCBC-48D7-8624-9A7C314C1590-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-12-20 13:50                           ` Daniel Pittman
     [not found]                             ` <87skojrm5e.fsf-zvVxMF7wGoXk1uMJSBkQmQ@public.gmane.org>
2008-12-20 18:22                               ` Dave Jones [this message]
2009-01-07 16:04                                 ` Hannes Reinecke
     [not found] ` <20081217193151.GA7356@hmsreliant.think-freely.org>
     [not found]   ` <20081217193151.GA7356-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2008-12-17 19:48     ` Jeremy Katz
     [not found]       ` <1229543309.28858.163.camel-T9xAYgMuJli44ywRPIzf9A@public.gmane.org>
2008-12-17 20:17         ` Neil Horman
2008-12-17 20:29         ` Kay Sievers
     [not found]           ` <ac3eb2510812171229g57eee496o6ad9e2fa97609455-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-12-17 21:06             ` Neil Horman
     [not found]               ` <20081217210645.GC7356-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2008-12-17 21:15                 ` David Zeuthen
     [not found]                   ` <1229548507.1229.4.camel-v34h5/LVXhbZaaYASwVUlg@public.gmane.org>
2008-12-17 21:22                     ` Neil Horman
2008-12-18 14:07             ` Karel Zak
2008-12-18  9:27     ` Loïc Grenié
2008-12-17 18:54 Jeremy Katz

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-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=daniel-zvVxMF7wGoXk1uMJSBkQmQ@public.gmane.org \
    --cc=initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=katzj-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=tytso-3s7WtUTddSA@public.gmane.org \
    /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