Re: Userspace ACPI interpreter ( was RE: [ACPI] [RFC] dev_acpi:support for userspace access to acpi)

[Len Brown]

Re: why would we want a user-space interpreter?

I don't see any strong reasons.  This is sort of an indulgent "what if"
topic...

Sure page-able memory is better to use than locked down kernel memory. 
Indeed, if the target system doesn't support ACPI at all, then we could
free all of ACPI's memory (static sizes listed below).  But this
configuration is becoming less common over time, not more common.
And if you've got a tiny system w/o ACPI, you'd probably just build with
CONFIG_ACPI=n rather than running a general-purpose ACPI-enabled kernel.

[ It would be sort of neat if we could built the core ACPI support in
some kind of modular way such that that we could have it at boot-time,
if we need it, but optionally unload it at run-time if it turned out the
target system didn't need it. ]

I suppose that a crash in the kernel-mode-interpreter would kill the
system.  But I'm not aware of any such failures today and we fix those
pretty quickly when they do happen.  From a high-level view, however,
Luming's simplicity=stability argument has some merit when you add in
things like memory leaks, stack overflows and all the other system
killing things that could potentially happen in the kernel.

In the kernel we currently have an issue running AML with interrupts off
-- can't do it b/c arbitrary AML could require allocating memory and
sleeping.  But this issue probably has a solution and by itself doesn't
justify a user-land interpreter.

One could argue that the _policy_ drivers -- the modules listed below
should live in user-space because they implement policy.  This, however,
is a philosophical, rather than practical, argument.


Re: why would we NOT want a user-space interpreter?

We need one in the kernel to boot the system anyway, so why have two?

Synchronization and concurrency in the kernel is well controlled.

No issues with AML accessing arbitrary ports and addresses when running
in the kernel.

-Len

---

CONFIG_ACPI_DEBUG=n

Loadable Module Sizes:
   text    data     bss     dec     hex filename
   1072     324       4    1400     578 drivers/acpi/ac.o
   8511    1624      20   10155    27ab drivers/acpi/asus_acpi.o
   5227     216       4    5447    1547 drivers/acpi/battery.o
   2006     452      16    2474     9aa drivers/acpi/button.o
    956     216       4    1176     498 drivers/acpi/fan.o
   9714    1057     372   11143    2b87 drivers/acpi/ibm_acpi.o
   9465    1012     128   10605    296d drivers/acpi/processor.o
   5891     868       8    6767    1a6f drivers/acpi/thermal.o
   3044      72      20    3136     c40 drivers/acpi/toshiba_acpi.o
   7824    1348       4    9176    23d8 drivers/acpi/video.o

Static Kernel Size:
   text    data     bss     dec     hex filename
 144533    5608    4920  155061   25db5 drivers/acpi/built-in.o


CONFIG_ACPI_DEBUG=y

   text    data     bss     dec     hex filename
   2234     356       4    2594     a22 drivers/acpi/ac.o
   8511    1624      20   10155    27ab drivers/acpi/asus_acpi.o
   7686     248       4    7938    1f02 drivers/acpi/battery.o
   3420     484      16    3920     f50 drivers/acpi/button.o
   1886     248       4    2138     85a drivers/acpi/fan.o
  18508    1044     128   19680    4ce0 drivers/acpi/processor.o
  11119     868       8   11995    2edb drivers/acpi/thermal.o
   3044      72      20    3136     c40 drivers/acpi/toshiba_acpi.o

Static Kernel Size:
   text    data     bss     dec     hex filename
 282285    6636    5112  294033   47c91 drivers/acpi/built-in.o


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/