On Sat, Mar 24, 2012 at 11:49:38AM -0700, H. Peter Anvin wrote:
> Yes... unfortunately between the kernel.org disaster and having a baby I
Congrats on the second one!
> 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,
That actually makes sense for ucode because we want it as early as
possible.
> 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.
One other downside for this approach would be the need to have
initrd/initramfs support always compiled into the kernel in order to do
all those things but, hey, distro kernels already have that so we're
probably stuck with it anyway.
And, if someone wants to add the support to the bootloader later, he
can still do that by handing in cpio archives to the kernel for further
processing...
--
Regards/Gruss,
Boris.
--
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
