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