[Adding Harald Hoyer, maintainer of dracut. Harald, we're discussing adding components to the initrd blob which is used during early boot. We have at least two such users identified: microcode updates and ACPI override. The two proposals on the table is either to stick with cpio format and using a special namespace (e.g. kernel/) or using a new header for these early objects that would be skipped by the initramfs decoder.] On 03/24/2012 02:24 AM, Borislav Petkov wrote: > On Fri, Mar 23, 2012 at 09:43:09PM -0700, H. Peter Anvin wrote: >> By the way, if "relying on the bootloader" was an option in any way then >> we would already have a solution in the form of the kernel data linked >> list. Unfortunately to the best of my knowledge not a single bootloader >> provides support for it. > > ... and that's unfortunate because if we had that support, we wouldn't > need to redo the initrd each time microcode or BIOS tables change but > simply point the boot loader to the updated images. > > :-( > > Btw, hpa, didn't you have someone working on early microcode loading, > any results there? > Yes... unfortunately between the kernel.org disaster and having a baby I haven't had enough to time to get that work out of the freezer, which is unfortunate in the extreme. On the other hand, perhaps it is a good thing we didn't end up settling on a protocol which was too narrow purpose for that one, too. This is my current thinking, and please comment on this so we don't spend a bunch of time bikeshedding this one... I'd like to come up with something that we can implement and move on. I have to say I'm personally leaning in the direction of just using a special namespace and still encode things as cpio. However, in order for that to work we need to make sure that the invariant "early kernel objects come before any compressed blob" is maintained at all times, which might be sensitive. However, it has serious advantages both from a bootloader UI point of view (names are ASCII strings) and from a tools point of view (it's just cpio, still.) The main downside is that the cpio header is mostly in ASCII encoded hexadecimal, which adds to the amount of code that needs to be ported into "special" environments... not a problem for the ACPI converter but for the early microcode it matters. I might try to throw a minimal walker together and see how much code it is, unless someone beats me to it ;) -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
