[OLPC-devel] Re: Why ACPI DSDT tables?

[Stefan Reinauer]

* David Woodhouse <dwmw2 at infradead.org> [060710 21:18]:
> > I hate writing new interfaces, but is it worth the pain of making
> > ACPI work just so we don't have to do any work in the kernel to get
> > the battery status? 
> 
> Definitely not. Even if we end up 'emulating' /proc/apm like everyone
> else does, instead of taking this opportunity to fix the kernel<->user 
> interface properly, it's better to do it with proper drivers.

What we want is a clean design. Ok, ACPI is not. Emulating /proc/apm is
neither.

The kernel<->user interface is crap, as it is in fact a stripped down
version of a very specific firmware<->kernel interface. We might not
want to fix this problem in _this_ scope.

When we're looking at firmware<->kernel or rather hardware<->kernel if
we omit acpi, it really does not matter too much where we settle the
relevant code except for some implementational details.

I have been implementing a lot of ACPI in LinuxBIOS because there
are setups that are simply impossible to boot with Linux otherwise.
No hardware reason, just design of the code flow. Fixing the kernel
would have exceeded any available resources (and probably made me a lot
of enemies with all the untested boards out there)

So before we talk in big words of ACPI or no ACPI, what parts do we
need from userspace:

 * cpu powerstates
 * display powerstates
 * other parts of the system that can be powered down?
 * poweroff, reboot, halt
 
 * what else? (and don't just write "ec")


Stefan


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/