Hi Jeremy,
Jeremy Katz wrote:
On Dec 19, 2008, at 3:21 AM, Hannes Reinecke wrote:
Jeremy Katz wrote:
(dropping lkml again)
On Thu, 2008-12-18 at 08:36 +0100, Hannes Reinecke wrote:
By instead moving to where we're basing everything off of uevents we can
hopefully move away from the massive shell scripts of doom, speed up
boot and also maybe get to where a more general initramfs can be built
_with the kernel_ instead of per-system.
Believe me, I tried. But it's _hard_, if not impossible.
Nothing that's easy is fun or worth spending time on :-)
Truly spoken :-)
One thing we should clarify, though:
What is the overall goal of dracut?
Should it create an streamlined initramfs, containing as little code
as possible and booting exactly on the system it was created on?
(IE creating a SUSE-style initramfs)
Or should it create a build-once-run-everywhere initramfs?
Build-one-run-everywhere. In fact, until yesterday, it really couldn't
be built on the system it was to be booted on. :)
Ah.
If you were going with the former, you face the challenge that you
have to initialize the root fs _only_, and skipping all other systems.
Hence you have the challenge to include the required udev rules only.
And, most obviously, you have to _detect_ the root fs. And make sure
to configure the underlying block devices properly.
And suddenly you end up with zillions of bash code, just to detect the
root fs.
Yep. I think we all know what this looks like
Indeed.
If you were to go with the build-once-run-everywhere approach, you'd
have the advantage that you could copy the udev configuration over.
And in theory you could then configure the entire system with udev.
Well, after someone fixed up LVM to work properly with udev, that is.
But the problem here is: it's quite impractical to include support
for every possible configuration. Normal block devices, ok.
LVM, MD, sure. Multipath, yes, of course. iSCSI ... yes, but,
should we include _all_ NIC modules? Do we even _ship_ all of them?
And which network modules to we need? Netfilter? VPN support?
As my last mail said, I suspect that once we start talking about some of
the network boot methods, you have to "buy-in" as they do have a
non-trivial cost. Including all the network modules, though, really
isn't much worse than all the storage drivers. Actually, I think it was
better the last time I checked.
So either we include _all_ kernel modules (which consume at the
last count 82 MByte) or make a shortcut here and there.
Which goes against the initial goal of the build-once-run-everywhere
approach.
Well, you don't need _all_. I've yet to come up with a convincing
reason to want the sound drivers for example :)
Don't let this hear the folks from disability support :-)
For the same reason I've ended up having to include USB
modules as occasionally someone has to enter a password
and might have a USB keybord.
And I'm quite convinced you can find a setup for nearly
every driver included in the kernel.
And as you admitted we won't be including _all_ modules,
so we don't _actually_ support the 'built-once-run-everywhere'
approach.
So we should be focussing on the 'build-once-run-mostly-everywhere'
approach to enable the trivial systems to boot.
And add a API / Extension something for the non-trivial systems.
And yes, everywhere is really more like everywhere(*) -- the stock
config being "local block devices" but with the ability to expand out
and support the more esoteric cases.
I do agree the latter approach is more appealing, but so
far I haven't found a proper solution for the kernel module
problem.
Kernel modules compress well and modprobe supports loading gzipped
modules. That helps the size aspect at least somewhat
Agreed.
No, I favour a completely different approach: Link the required
modules into the kernel. When we run the mkinitrd prg (or whatever
it's called) to create
the initrd, we will be detecting the modules which are required
to boot the kernel and mount the rootfs.
If it were now possible to link these modules into the kernel
directly via some 'ld' magic, we could get away with loading
just one kernel image without any initramfs. No modprobe,
nothing. That would be _fast_. And we would be having the
advantage that we could kexec into the 'normal' boot image
with initramfs if this 'single shot' approach doesn't work.
You still have to have an initramfs as you aren't going to have the
logic for LVM activation in the kernel. Or to handle resume from
hibernate. Or dm-crypt. Etc. So an initramfs is really something akin
to a requirement for non-trivial systems. And the speed really isn't a
fundamental factor of dealing with an initramfs. I was actually quite
surprised by how fast I was able to boot with a dracut-generated initramfs
No, you don't. Those systems I'd consider non-trivial and should be handled
from a 'real' initramfs.
The trivial system would be one where just loading a module will make the device
appear (ie simple ATA / SCSI systems).
Once you need something more or different you'll have to use a proper initramfs.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
