Re: [Fwd: Overriding ACPI tables]

[Eric Piel <eric.piel@tremplin-utc.net>]

> Thomas Renninger wrote:
>> Peter: You wrote the syslinux stuff, right? What kind of luck is that :)
>> There currently is a discussion about being able to override ACPI tables
>> via initrd. The discussion is a bit stuck because the data is needed
>> earlier than initrd is unpacked and the hacks to make it work are not
>> accepted by Linus. I thought about adding another binary image to i386
>> boot protocol, similar to initrd= which contains data for very early
>> kernel boot initialization, but this would be a heavy hammer (but IMO
>> still better than only do it for kexec, another suggestion...) , I
>> better open a separate thread or pre-ask privately whether this makes
>> sense at all. It would be great if you could advise and possibly help to
>> convince so that we finally may find a solution accepted mainline.
> 
> We're putting in a mechanism for pushing larger tables already; we need 
> it for other things (in particular, the zones for E820 and EDD in the 
> boot_info_table are simply not big enough.)  That gives a generic 
> mechanism for sending arbitrary-sized binary images to the kernel.  That 
> would be the mechanism to use.
> 
> I believe it's in upstream as this merge window; it's definitely in 
> x86.git already.
Hi Peter,

Thank you for the pointer. You are talking about setup_data, right? I'll 
try to use it for reading the DSDT table. I have a couple of questions 
though:
* I can find reference of it only in setup_64.c, is it planned to add 
support also for 32bit? (That's a must for me)
* From inside the kernel, all I have to do is to add a hook inside 
parse_setup_data(), allocate memory and I'll be able to copy the data 
into this safe place, right?
* Is there any bootloader which already has support for this extension? 
  By chance, would you have a patch for grub?

See you,
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html