Re: module 90kernel-modules-loaded

[Hannes Reinecke <hare-l3A5Bk7waGM@public.gmane.org>]

Hi all,

Harald Hoyer wrote:
> Jeremy Katz wrote:
>> On Friday, March 06 2009, Victor Lowther said:
>>> On Fri, 2009-03-06 at 15:39 -0500, Bill Nottingham wrote:
>>>> Victor Lowther (victor.lowther-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) said:
>>>>>>> http://git.surfsite.org/dracut.git
>>>>>>> git://surfsite.org/pub/git/dracut.git
>>>>>> Wasn't the entire point to make the initramfs generic?
>>>>> No, to make the initramfs generator generic. A subtle but important
>>>>> distinction.
>>>> Nope. The plan was (quoting earlier mails to the list, from the
>>>> creators...):
>>>>
>>>> ...
>>>> [I]nstead of scripts hard-coded to do various things, we depend on
>>>> udev to create device nodes for us and then when we have the
>>>> rootfs's device node, we mount and carry on
>>> We do this just fine.  Udev is the engine that drives everything in a
>>> dracut-generated initramfs -- the additional scripts are there in the
>>> initramfs to handle things that udev does not handle gracefully. If you
>>> see some functionality currently handles in a script that udev could
>>> handle better, please implement it.
>>
>> The problem is the direction seems to be "hm, udev can't do this, guess
>> we'll make a hook" rather than "fix udev and the underlying tools".
>> Yes, it means it's harder.  And yes it means that distros have to get
>> updates for everything to work.  But otherwise, we remain in the past
>> with piles of scripts doing most things.
>>
> 
> Problems so far:
>     - dmraid (raid assembly)
>     - device mapper handled /dev/ symlinks

That's hardly a udev issue. We should rather be fixing device-mapper to
work together with udev.

But yes, dmraid (and multipath) are the hard problems.
dmraid is probably okay, as you can eg just add a '--export' to dmraid
to print out all found signatures. Then write some rules which latch
on these exported variables and start dmraid if all component devices
have been discovered. Easily done with eg the 'collect' utility from
udev extras.
Problem with multipath here is that you can't detect a multipathed
device a priori. It's basically a policy decision whether the user
wants to start multipath or not. So you basically have to write
some device-specific udev rules for enabling multipath on some
devices.
The hard part here is to remove the component device from the list
of eligible devices so that eg LVM doesn't erroneously tries to
scan from a multipath or dmraid component device.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare-l3A5Bk7waGM@public.gmane.org			      +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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html