On Mar 4, 2009, at 10:40 AM, Seewer Philippe <philippe.seewer@xxxxxx>
wrote:
Victor Lowther wrote:
[snip]
Second I have to ask how far Dracut needs (and wants) to go with
the "One initrd to rule them all". The different distros will need
to customize the initrd anyway. Think in terms of splash-screens,
different versions of utilities and configs or just plain 'crazy
and convoluted'...
I would have the goal of making dracut be able to generate a
working no-frills initramfs with minimal (preferably no) distro
customization, and have a hook structure that allows the distros to
customize the initrams without having to patch things.
Yes, that's why I suggested Fallbacks (or maybe we should call them
"sane defaults").
I see a few problems with the modules/hook structure though: If, for
example, we provide a generic find-modules and the distro wants
completely other functionality, that part of Dracut would have to be
changed/disabled. That's a "patch" for me.
Hmmm... I am not seeing the difficulty here. Perhaps a code snippet or
a more detailed use case would help.
[snip]
I'm thinking of a debootstrappish system of suite/target (or topic/
flavour) where Dracut specifically delegates those tasks away it
cannot solve on its own. We might even provide some simple things
like just including all drivers for testing purposes or as a
fallback solution.
Let's see how the current modules/hooks mechanism works for now. We
can extend or scrap it if it turns out to not suit our needs.
I was thinking a bit along the line of what should be included on a
netboot initrd. Personally I wouldn't want to see hooks for
cryptsetup or lvm in it. Hence the idea of suite/target to select
maybe a distro (could be 'dracut' for generic) and different targets
(might be netboot or a combination of block,crypt,lvm).
That can be handled by having an /etc/dracut.conf that contains a
dracutmodules="my modules here" line. The default is "all", which
loads all the modules on initramfs creation. Extending that
functionality should not be a problem to define some defaults other
than including everything.
But well... I guess I'm violating list rules again. Patches speak
more than words, I'll see what I can cook up.
I look forward to them. :)
--
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
