It doesn't really gain anything from being static, aside from requiring odd udev rules and/or init scripts to load it.
Bill
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 ?
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
or
- pretend the request_firmware didn't happen, and have the initscript continue to do the microcode_ctl
Which direction are we moving in ?
Dave
Dave Jones (davej@redhat.com) said:
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 ?
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
or
- pretend the request_firmware didn't happen, and have the initscript continue to do the microcode_ctl
Which direction are we moving in ?
AIUI, the driver's firmware request will get kicked off again when udev triggers all the normal coldplug events. So, that should be handled OK.
Bill
On Wed, Jan 14, 2009 at 03:20:01PM -0500, Bill Nottingham wrote:
AIUI, the driver's firmware request will get kicked off again when udev triggers all the normal coldplug events. So, that should be handled OK.
groovy. Should be safe to do then. Given we're always loading this on Intel (and I think AMD), might as well build it in.
Dave
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
Adam Jackson (ajax@redhat.com) said:
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.
There's the MODULE_FIRMWARE tag, but it obviously doesn't handle runtime-generated firmware names.
Bill
On Wed, 2009-01-14 at 15:26 -0500, Bill Nottingham wrote:
Adam Jackson (ajax@redhat.com) said:
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.
There's the MODULE_FIRMWARE tag, but it obviously doesn't handle runtime-generated firmware names.
Hmm. Wrap all firmware in ELF EM_NONE headers, add modinfo sections so we can pattern match?
- ajax
On Wed, Jan 14, 2009 at 03:24:43PM -0500, Adam Jackson wrote:
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".
sure.
If you actually need the microcode to get out of initramfs, you have already lost, and this move won't change anything.
We've only ever had one case where an updated microcode was required to boot, and that was on pre-production hardware, so I don't think it's really that critical.
Dave
On Wed, 14 Jan 2009 13:49:57 -0500, Dave Jones davej@redhat.com 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.
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..
A trick exists to go around it: http://people.redhat.com/zaitcev/linux/linux-2.6.27-204396-5.diff
If you recall, libusual has the same problem if it's built in.
-- Pete
kernel@lists.fedoraproject.org
-
Adam Jackson -
Bill Nottingham -
Dave Jones -
Pete Zaitcev