[ACPI] [RFC] dev_acpi: support for userspace access to acpi

f you want to have a full access to acpi subsystem from userspace, why not firstly move ACPI interpreter out of kernel?
Then, you can play with the whole ACPI subsystem with minimal cost of troubling kernel in userspace. Say, you can forget "
ioctl, read issues on files, complex data for sysfs, file per operation, etc...". Is it a more clean way ?

Thanks
Luming

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

The kernel certainly needs an ACPI interpreter and it needs it before
userspace is launched. Handing off the interpreter to userspace or
managing two interpreters poking ACPI at the same time seems like a much
more complicated problem. The kernel is the primary consumer, I think
it would just shift the problem elsewhere to consider moving it.

The problems quoted below were from the previous sysfs interface I was
developing. I think these problems are fixed with this current device
file interface. I'm hoping dev_acpi is already more clean. Thanks,

Alex

On Wed, 2004-10-27 at 10:30 +0800, Yu, Luming wrote:
--
Alex Williamson HP Linux & Open Source Lab

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

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.

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.

But, Not sure what's the evil consequence from this approach. Say, if kernel need service
from ACPI interpreter, ACPI interpreter should be get scheduled. Is it racy?

Thanks
Luming

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