[arch-projects] [mkinitcpio][PATCH 00/19] Break all the things!

[Thomas Bächler]

Am 14.05.2012 15:50, schrieb Dave Reisner:
>> In the past, udev needed to run before the modules listed in MODULES=
>> from mkinitcpio.conf were loaded. Otherwise, firmware loading would
>> fail, and almost everyone with MODULES="radeon" would be very unhappy! I
>> know that some things have changed regarding firmware loading since
>> then, but this is likely still an issue in some form - and even if it
>> isn't, it is a good idea to have a firmware helper present before doing
>> anything.
>>
> 
> Excellent point -- was curious about this myself. I asked Kay about
> it:
> 
> 08:50         kay  » it will be catched with the coldplug run, yes
> 08:50         kay  » but if udev runs in intramfs, and there is no firmware
>                      file, the request will be canceled

That should be taken care of.

> 08:51  falconindy  » yeah, this is initramfs
> 08:51  falconindy  » so settle will play catchup and things will
>                      just work (hopefully)
> 08:57         kay  » settle?
> 08:57         kay  » trigger will
> 08:58  falconindy  » even better
> 08:58         kay  » but if udev from initramfs still runs and
>                      there is no firmware file, all is discarded
> 
> So it seems to me that we're covered here since we assume that the
> firmware is present (or else its a bug in mkinitcpio). I'd like to get
> someone with perhaps a radeon to confirm this via my working branch and
> a modified udev hook (I can provide this), but I guess the worst case
> scenario is that we file a bug.

Back in the day (haha), udev still worked with modules waiting for
firmware in module_init. But running 'modprobe foobar; udevd --daemon'
would wait for the timeout and start udev afterwards.

Starting udev before module loading is safe and also works with old
versions. If these bugs are all fixed, then Kay is of course correct.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-projects/attachments/20120514/6270f118/attachment.asc>