[haiku-development] Re: ACPI development
- From: <philippe.houdoin@xxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 05 Dec 2008 12:27:43 +0100
Hi,
> Do we want the acpi bus manager to be a bus manager like the other new
> ones, publishing devices, and having a directory with drivers for this
> particular bus implementing support for the acpi devices?
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.
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.
Speedstep support may be one exception here, though, as I guess the kernel
may be interested too.
My .02 cent. Which worth less every minute. ;-)
Bye,
Philippe.
Other related posts:
