[lkml]   [2012]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] ACPI: Implement overriding of arbitrary ACPI tables via initrd
On Saturday 24 March 2012 03:01:28 H. Peter Anvin wrote:
> 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 guess this would not be the first time a good feature has been added,
knowing that a more general API will be build around it later.
10 lines are really easy to adopt.

> 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.
Can this be implemented without using dynamic memory allocations?
If not, it's not suitable for early APCI overriding.

> 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?
Whatabout Multiboot(2):

They do it similar to 2, but without specifying the data of the
files like you do with type.

It's a bigger thing, but I could imagine there are some guys who would
be willing to give it a try. I remember I googled a multiboot patch
which got submitted to lkml long time ago.

It has it pros and cons, but should show up in such a discussion.


 \ /
  Last update: 2012-03-24 04:05    [W:0.075 / U:11.800 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site