>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
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
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.
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
>
>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?
One reason for kernel-mode interpreter is to live in unpageable memory.
User-mode ACPI interpreter advantages:
1. Without losing platform functionality, user-mode interpreter
can make kernel less complex, thus more stronger.
2. Kernel can release from AML issues.
...
Thanks,
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
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
> [ 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. ]
It would be possible with some Makefile hacks. Basically you would need
to objcopy the ACPI object files and rename .text*/.data* to
a different acpi specific name. Then you can give it an special
area in the vmlinux.lds and possibly free it.
I agree with you that it's better kept in the kernel.
> Static Kernel Size:
> text data bss dec hex filename
> 144533 5608 4920 155061 25db5 drivers/acpi/built-in.o
Hmm, this used to be smaller, no? Perhaps someone going over
bloat-o-meter[1] output to an older version would be useful.
There is probably some low hanging fruit.
-Andi
[1] ftp://ftp.firstfloor.org/pub/ak/perl/bloat-o-meter
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!