Hi Jeremy,
Jeremy Katz wrote:
(dropping lkml again)
On Thu, 2008-12-18 at 08:36 +0100, Hannes Reinecke wrote:
We definitely should get together to hammer our one implementation.
Having different scripts for every distributions is a PITA.
Indeed -- but as davej noticed, going with one distro's implementation
is unlikely to fly and so we need to start over
I'm not saying my implementation is the greatest on earth, so
if anyone has any better suggestions I'm all ears.
I had actually looked at it some a couple of months ago when the
discussion started, but it looked like the same thing that an
initramfs/initrd has always been -- piles of shell scripts that are
strung together based on what the system building the initramfs looks
like. The problem is that you then a) have a fair bit of system
dependence in the initramfs b) spend a lot of time running shell
scripts.
Granted for both points. However, I tried to get the information
from the running system by querying programs / sysfs directly and
_not_ relying on any configuration scripts. So that should alleviate
point a) slightly.
b) is, sadly, true.
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.
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?
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.
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?
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.
I do agree the latter approach is more appealing, but so
far I haven't found a proper solution for the kernel module
problem.
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.
Oops. That was longer than expected. Anyway.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
[email protected] +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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
