On Wed, 2009-01-14 at 13:49 -0500, Dave Jones wrote: > On Wed, Jan 14, 2009 at 01:17:38PM -0500, Bill Nottingham wrote: > > It doesn't really gain anything from being static, aside from requiring > > odd udev rules and/or init scripts to load it. > > We had this discussion yesterday on irc, but I never really got this in my head. > > It works ok with microcode.dat, but what happens if Intel release > an update in /lib/firmware/intel-ucode/$f-$m-$s format ? Just to be clear, by "works ok" you mean "we request_firmware() for f/m/s and get nothing, and then some time later an initscript loads microcode.dat instead". If you actually need the microcode to get out of initramfs, you have already lost, and this move won't change anything. > The driver will do a request_firmware, but if we build the driver in, > we'll be in the initrd, where that file won't exist. > To make it work, we'll either have to.. > > - have the firmware in the initramfs Do we have any way of querying the kernel for firmware requests it will itself make? I don't think we do, let alone the ability to notice pattern matches like f/m/s. - ajax
_______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-kernel-list
