[haiku-development] Re: ACPI development
- From: "Ithamar R. Adema" <ithamar@xxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 05 Dec 2008 12:52:37 +0100
Hi Philippe!
philippe.houdoin@xxxxxxx wrote:
If we could keep as much as possible specifics "drivers" out of kernel, I'm
all for it.
ACPI "bus" manager needs to run in kernelland, but for the rest what we
really needs first is a way to expose it's API to userland.
Usually, we does this via a "raw" driver, publishing thru a
/dev/bus/acpi/raw entry a public API.
Above that, userland add-ons does the job.
Yes, I remember. A lot akin the usb userland kit I guess.
I really don't see why exploring namespace, monitoring buttons, batteries,
lid, and controling whatever leds of builtin MFD and like should need a
code to run at kernel level, when userland would be far enough. And safer.
Buttons and lid ACPI events are good candidates for an input_server add-on,
for exemple.
Agreed. That was more or less what I was thinking, and will get back to
discussing the details of this here once I've seen that ACPI is actually
working correctly. You can see this pattern already as all acpi_*
drivers seem to implement a read hook that outputs ASCIIZ text for easy
cat-ting ;)
Speedstep support may be one exception here, though, as I guess the kernel
may be interested too.
Yeah, ACPI is really divided up in extended-PnP-like functionality
(truely low-level, kernel material) and high-level events (aka Lids,
hotkeys, kill switches, etc).
My .02 cent. Which worth less every minute. ;-)
Still valuable none-the-less ;)
Ithamar.
Other related posts:
