From: Thomas Renninger <trenn@suse.de>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: eric.piel@tremplin-utc.net, vojcek@tlen.pl, dsdt@gaugusch.at,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
x86@kernel.org, Lin Ming <ming.m.lin@intel.com>,
lenb@kernel.org, robert.moore@intel.com,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH] ACPI: Implement overriding of arbitrary ACPI tables via initrd
Date: Mon, 26 Mar 2012 02:45:42 +0200 [thread overview]
Message-ID: <201203260245.43177.trenn@suse.de> (raw)
In-Reply-To: <4F6D50DD.4050306@zytor.com>
On Saturday 24 March 2012 05:43:09 H. Peter Anvin wrote:
> On 03/23/2012 08:02 PM, Thomas Renninger wrote:
> >>
> >> 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.
> >
>
> No, what you want is to add a new interface, which is going to have to
> be maintained indefinitely. That's the problem.
It's a debug option...
Best would be if no distro specific mkinitrd magic is needed and it's
just as easy as it is:
cp DSDT.aml /boot/initrd-test
cat /boot/initrd >>/boot/initrd-test
and add a test boot entry to grub's menu.lst or whereever.
Then developers would not have to look at distro specific implementations
(which should not exist) about how to test a table quickly.
> >> 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.
>
> Yes it can, as long as it is uncompressed. It just becomes a matter of
> walking the cpio headers which is effectively a linked list.
>
> It is more code than the simple header option, though.
>
> By the way, if "relying on the bootloader" was an option in any way
Why exactly is a change in the bootloader not an option?
Not sure whether a version number is passed, but the magic number could be
changed for now.
> 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.
If the new magic number is passed, we get a linked list.
Otherwise we get it the old style and can still support that for several
years.
I agree that this should not be subject to change every here and there, but
"never ever change..." sounds as if something went wrong.
This is just an interface to the kernel, some apps, called bootloaders are
making use of?
It's not that I want to propagate a bigger change, I am all for the quick change
and proceed solution, I just wonder why above is not possible.
Thomas
next prev parent reply other threads:[~2012-03-26 0:45 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-23 14:29 [PATCH] ACPI: Implement overriding of arbitrary ACPI tables via initrd Thomas Renninger
2012-03-23 15:51 ` Thomas Renninger
2012-03-23 20:05 ` H. Peter Anvin
2012-03-24 1:42 ` Thomas Renninger
2012-03-24 2:01 ` H. Peter Anvin
2012-03-24 3:02 ` Thomas Renninger
2012-03-24 4:40 ` H. Peter Anvin
2012-03-24 4:43 ` H. Peter Anvin
2012-03-24 4:50 ` Yinghai Lu
2012-03-24 4:58 ` H. Peter Anvin
2012-03-24 9:24 ` Borislav Petkov
2012-03-24 18:49 ` H. Peter Anvin
2012-03-25 8:54 ` Borislav Petkov
2012-03-26 1:36 ` H. Peter Anvin
2012-03-26 14:21 ` Konrad Rzeszutek Wilk
2012-03-26 0:45 ` Thomas Renninger [this message]
2012-03-26 1:25 ` H. Peter Anvin
2012-03-26 14:19 ` Thomas Renninger
2012-03-26 14:46 ` H. Peter Anvin
2012-03-26 14:51 ` Thomas Renninger
2012-03-27 4:15 ` H. Peter Anvin
2012-03-27 4:46 ` Peter Stuge
2012-03-27 6:18 ` H. Peter Anvin
2012-03-24 18:42 ` Konrad Rzeszutek Wilk
2012-03-24 19:15 ` H. Peter Anvin
2012-03-24 19:17 ` Konrad Rzeszutek Wilk
2012-03-24 19:44 ` H. Peter Anvin
2012-03-24 22:21 ` H. Peter Anvin
2012-03-24 22:44 ` H. Peter Anvin
2012-03-25 9:25 ` Borislav Petkov
2012-03-25 23:29 ` H. Peter Anvin
2012-03-25 4:17 ` H. Peter Anvin
2012-03-25 9:07 ` Borislav Petkov
2012-03-23 20:54 ` Yinghai Lu
2012-03-24 0:15 ` Yinghai Lu
2012-03-24 1:05 ` Yinghai Lu
2012-03-24 1:22 ` Thomas Renninger
2012-03-24 1:26 ` Thomas Renninger
2012-03-24 4:41 ` Yinghai Lu
2012-03-26 0:45 ` Thomas Renninger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201203260245.43177.trenn@suse.de \
--to=trenn@suse.de \
--cc=dsdt@gaugusch.at \
--cc=eric.piel@tremplin-utc.net \
--cc=hpa@zytor.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.m.lin@intel.com \
--cc=robert.moore@intel.com \
--cc=viro@zeniv.linux.org.uk \
--cc=vojcek@tlen.pl \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox