'Twas brillig, and Anssi Hannula at 15/12/11 13:07 did gyre and gimble: > On 05.12.2011 22:37, Colin Guthrie wrote: >> 'Twas brillig, and Anssi Hannula at 02/12/11 21:17 did gyre and gimble: >>> On 02.12.2011 15:57, Anssi Hannula wrote: >>>> On 02.12.2011 13:28, Colin Guthrie wrote: >>>>> Hi, >>>>> >>>>> Just a suggestion! Should we move wholesale to dracut? >>>>> >>>>> It's very easy to hack on, and Harald Hoyer has been very helpful and >>>>> has merged some of the patches we carried locally (which I mostly copied >>>>> from Mandriva). Not sure why they were not upstreamed before. >>>>> >>>>> There are still a couple patches we carry locally (soon to be less when >>>>> Harald pushes his git repo and I rebase), but they are pretty trivial, >>>>> understandable and easily maintainable (mostly they will be stylistic >>>>> tweaks and naming variations - i.e. very minor). >>>>> >>>>> Modprobe rules are included even in the initrd so tweaks there follow >>>>> through. >>>>> >>>>> I'm not necessarily against keeping mkinitrd, but I think we should take >>>>> the time from now until the beta phase to obsolte mkinitrd and force >>>>> everyone to use dracut in order to see if there are any issues and then >>>>> make the call before next beta or rc. >>>> >>>> +1 >>>> >>>> One thing that doesn't work with dracut yet is that it only includes the >>>> KMS drivers into initramfs if they are loaded at the time of initramfs >>>> creation, causing unoptimal boot screen when a) initramfs created by the >>>> installer (I guess), and when b) user has switched a driver non-kms -> kms. >>>> >>>> This can probably be solved by some patching of >>>> modules.d/50plymouth/module-setup.sh, but I haven't looked at it closely >>>> yet. >>> >>> Patch attached. I guess this would remain as a Mageia specific patch as >>> the wanted behavior is dependant on how the distribution handles driver >>> switching etc... >>> >>> Shall I apply it? >> >> Just to pick up on this patch, here is a conversation I just had with >> Harald on #dracut IRC: >> >> coling> haraldh, the "more interesting" question (for various values of >> "more interesting") was about a how hostonly works.... at the moment it >> only includes modules that are already loaded... but in some cases you >> want to include modules that are not currently loaded but do belong on >> the h/w in question. >> <coling> haraldh, one of the patches (that we believe might just have to >> be a local one for the way we do things) is here: >> http://svnweb.mageia.org/packages/cauldron/dracut/current/SOURCES/0508-plymouth-Include-kms-modules-even-if-they-are-not-cu.patch?revision=175507&view=markup >> <coling> It checks the module aliases against the current h/w. We do >> this when we generate the initrd from the installer and include the KMS >> modules even although they are not currently loaded. >> <coling> I'm not sure if this is a mechanism you want to consider >> supporting? e.g. perhaps "hostonly" mode could change to do things this >> way (via modaliases) and a new "loadedonly" mode could suppliment >> hostonly to give the current behaviour? >> <coling> Or perhaps you could make hostonly={no|yes|loaded|hardware} >> where yes is just a synonym for "loaded". >> <coling> (I didn't write that patch by the way, so i'm just picking up >> on the general principal with a view to seeing if the general concept >> can be upstreamed) >> <haraldh> hostonly, hmm, yes, greping for currently used modules was the >> easiest and fastest way >> <haraldh> to be more correct, we should do it with the aliases like in >> your patch >> <haraldh> but that is costly and takes a lot of time >> <haraldh> and also the modprobe.conf.d is something one would want >> <haraldh> and also install possible helper tools there >> <haraldh> so, if you want to factor that one out in a module filter >> function, send it to the initramfs mailing list >> <haraldh> any help in that area is appreciated and most likely merged :) >> >> >> So if you fancy working on this, I'm sure it'll get upstreamed :) > > I might take a look at this. > > Though, as Harald says, it might prove to be slow, since we'd have to > compare every alias of every module considered by dracut against the > system modalias list... Well, I guess we'll see.
Yeah I guess it would be good to have the this cached into some kind of matrix, but that might be a bit tricky in sh... Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/