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

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

[Yu, Luming]

>On Wednesday 27 October 2004 10:04 pm, Yu, Luming wrote:
>> On IA64 platform, ACPI interpreter seems to be mandatory for those
>> stuff, but IA32 is not.  So, the ram disk is the generic solution 
>> for loading user space interpreter for boot. 
>
>In two sentences: If you want to play with moving the interpreter
>to user-space, please do so, and do it on ia64, so you have to
>deal with the interesting problems.
>
>And this whole thing is a gigantic tangent that is only distracting
>attention from the real question at hand, namely, Alex's dev_acpi
>patch, which exists today and enables some very interesting new
>functionality.
>

  Yes, I agree Alex's dev_acpi is interesting, which could result in 
the removal of some acpi specific drive such as battery.c, button.c,
fan.c, thermal.c ....   So, I raised the question of userspace ACPI 
interpreter.  Intuitively, userspace is the right place for interpreter.

Thanks,
Luming



-------------------------------------------------------
This Newsletter Sponsored by: Macrovision
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/

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

[Pavel Machek]

Hi!

> >> On IA64 platform, ACPI interpreter seems to be mandatory for those
> >> stuff, but IA32 is not.  So, the ram disk is the generic solution 
> >> for loading user space interpreter for boot. 
> >
> >In two sentences: If you want to play with moving the interpreter
> >to user-space, please do so, and do it on ia64, so you have to
> >deal with the interesting problems.
> >
> >And this whole thing is a gigantic tangent that is only distracting
> >attention from the real question at hand, namely, Alex's dev_acpi
> >patch, which exists today and enables some very interesting new
> >functionality.
> >
> 
>   Yes, I agree Alex's dev_acpi is interesting, which could result in 
> the removal of some acpi specific drive such as battery.c, button.c,
> fan.c, thermal.c ....   So, I raised the question of userspace ACPI 
> interpreter.  Intuitively, userspace is the right place for interpreter.

I do not think you want to put thermal/fan into userspace. If you boot
machine with init=/bin/bash, you should have working system. System
without fan fail... fast.

Plus you want to do suspend/resume.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

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

[Yu, Luming]

>On Wednesday 27 October 2004 11:17 am, Yu, Luming wrote:
>>   If don't use acpi_early_init , acpi is initialized in 
>do_basic_setup() in kernel thread --init.
>> It is very close to launch first user space 
>process(/sbin/init ..). So, if we can invent 
>> acpi_later_init, it is possible to move interpreter out of kernel.
>
>It's true that some early init stuff is based on the static tables
>and doesn't require the interpreter.  But there is a lot of stuff
>that DOES require the interpreter, like finding PCI root bridges,
>PRTs, PCI interrupt link devices, etc.  It's not clear to me that
>it's feasible to deal with all these from userspace.

On IA64 platform, ACPI interpreter seems to be mandatory for those
stuff, but IA32 is not.  So, the ram disk is the generic solution 
for loading user space interpreter for boot. 

>
>>   The difficulty for inventing userspace interpreter is to 
>eliminate the ACPI-interpreter dependency 
>> of drivers for booting. But this dependency is not 
>mandatory. Once kernel booted to be able
>> to launch /sbin/init, it is also able to launch 
>/sbin/user_space_interpreter, then kernel can enjoy
>> acpi from then on, despite the acpi interpreter is a user 
>space daemon, we just need to invent
>> or user a communication method between kernel and user space daemon.
>
>Before the interpreter, you don't have ANY devices (legacy ones are
>described via the namespace of course, and PCI devices depend on root
>bridges that are also in the namespace).  So you end up at least
>requiring a ramdisk, plus a bunch of encoding to communicate resource
>information from the interpreter to the drivers.
>
>Maybe not impossible, but it certainly requires a lot of work.  Moving
>the interpreter to userspace has been proposed many times, but I've
>never seen any indication that anybody is actually working on it.
>

Yes, it needs a lot of work.  If we want to continue, we should find out
what's the benefit of doing so. The biggest benefit could be that kernel
will be less complex, thus kernel will be more stable.  At least, some
ACPI operation (like information query) is not needed to be handled in
kernel in synchronous manner, which is kernel invoking ACPI interpreter
like calling a C function. On laptop, I DO get many bug reports that
kernel 
crashes, or hang for a while ,or input event lost..., just due to AML
call executed
by ACPI interpreter running in the kernel.  I expect all this symptom
will
be gone, if interpreter is running in user space.

Thanks,
Luming

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

[Len Brown]

One way to experiment with a user-mode ACPI interpreter would be to 
continue to use the kernel-mode interpreter for boot up , and cut over 
to the user-mode interpreter at /sbin/init.  The kernel-mode interpreter 
could be sent the way of free_initmem() which is called just before 
/sbin/init is invoked.

-Len

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

[Theodore Ts'o]

On Thu, Oct 28, 2004 at 01:37:52AM -0400, Len Brown wrote:
> One way to experiment with a user-mode ACPI interpreter would be to 
> continue to use the kernel-mode interpreter for boot up , and cut over 
> to the user-mode interpreter at /sbin/init.  The kernel-mode interpreter 
> could be sent the way of free_initmem() which is called just before 
> /sbin/init is invoked.

Is there a significant advantage to doing having a user-mode ACPI
interpreter?  The only advantage I can think of is that the ACPI
interpreter could now live in pageable memory.  Are there any others?

					- Ted


-------------------------------------------------------
This Newsletter Sponsored by: Macrovision 
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate 
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/

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