On 03/23/2012 06:42 PM, Thomas Renninger wrote:
>
> If there is any initrd change this could easily be adopted.
> Would be great to see this one pushed into 3.4 before a possibly long
> taking discussion about bigger initrd layout changes.
>
This should have been in linux-next before the merge window started, and
certainly "pushing it upstream before a possibly long talking discussion
about bigger initrd layout changes" is *definitely* putting the cart
before the horse ... almost nothing matters as much as avoiding
introducing a new protocol that we need to keep stable.
Sorry, it doesn't work that way.
I'm not too happy about the idea of using "naked" ACPI headers as the
sole discriminator, because they lack a strong magic. Furthermore, I
really don't want to see all the potential early-initrd users invent
different schemes for encapsulation, which has the potential of
cross-infection (early microcode update, for example, would have to be
invoked before ACPI, and needing that code to understand ACPI table
format is a nonstarter.)
I see two realistic options:
1. We use cpio encapsulation for everything, with a special namespace
for items used directly by the kernel, e.g. "kernel/".
+ Simple, existing tools can pick apart
- May lead people to believe that the early-initrd portion can be
compressed like the "normal" initrd portion, leading to strange
problems.
2. We create a new simple header (just a magic number, an identifier
for the type of data, and a length) for each of the early-initrd
objects:
struct early_initrd_header {
u64 magic; /* 0xa5a46ce422d8f5a1 */
u32 type; /* 1 = file data, 2 = ACPI, 3 = microcode... */
u32 length; /* Length of data object */
};
XXX: Should we make this a defined endianness (presumably
bigendian), or use host-endianness? I would guess the former might
be better...
Either of these allow one piece of code to quickly bypass bits that
doesn't belong to it.
Thoughts?
-hpa
--
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
