[OLPC-devel] Why ACPI DSDT tables?
Eric W. Biederman
ebiederm at xmission.com
Mon Jul 10 14:02:18 EDT 2006
Jim Gettys <jg at laptop.org> writes:
> I think David is making a good point here.
>
> I'd just as soon not be in left field on these interfaces unless there
> is a good reason, much as we detest ACPI.
Mostly agreed. If the user space interface to this stuff changes
when we have different firmware then the kernel really isn't doing
it's job and that is a problem that needs to be fixed regardless.
So I don't think a kernel<->user space interaction is a good
justification.
If there are drivers that we need that the kernel does not
have a good way of providing then that is a good justification
for avoiding ACPI.
So I recommend we stick with ACPI in user space for now (which
avoids the reflash cost) and do as little in ACPI as possible.
Then when we understand what needs to happen we can make stick
the ACPI tables in the BIOS if there are pieces we haven't
found a clean way to implement in Linux.
If all we are missing is a little bit about how components are
connected up and standard generic drivers could be used otherwise
I'd would like to through a LinuxBIOS table parser in there and
mark it as __init because that is one time knowledge.
Eric
More information about the Devel
mailing list