On Thu, 2008-07-03 at 06:56 -0700, Arjan van de Ven wrote:Actually there are three: 1. The text format 'microcode.dat', including updates for all CPUs. 2. The binary format output by microcode_ctl, still including all CPUs. 3. The smaller files with just the relevant subset of #2. The kernel (since 2006) can actually take either #2 or #3. The udev scripts I just posted will use microcode_ctl to feed it #2, when they find #1 on the file system. A small amount of extra work in the userspace tool would let those udev scripts feed #3 to the kernel, and then the code in the kernel to select the appropriate update could be removed. Doesn't the "new format" (#3) involve hard links too, since there are some cases where the same microcode update applies to more than one CPU revision? Do we really need to _ship_ it in a different form? It's not exactly hard to convert from the text form (#1) to either of the other two -- either on the fly in udev scripts, or at installation time. -- dwmw2 --
| James Bottomley | Re: Integration of SCST in the mainstream Linux kernel |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| majkls | sys_chroot+sys_fchdir Fix |
| Paul Mackerras | Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| KOSAKI Motohiro | [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
