From: Paul I. <pa...@ac...> - 2004-03-13 13:48:50
|
On Fri, 2004-03-12 at 16:42, Pavel Machek wrote: > > > Each object/device should have his methods as files in > > > /sys/firmware/acpi/ hierarchy. > > > To access a method, we should first "echo <arg1> ... <argn> > METHOD" to > > > set the arguments for that method, and when we "cat" the method, it > > > actually executes the method with our arguments, and return the result. > > Does not work; what if two people attempt to run the method > at same time? Well, my proposal was not for production kernels, it was simply a testing module that would help people play with various ACPI methods/events on their machines to find out what works and what not, and that is only enabled when ACPI debugging is compiled in and maybe some other option like "acpi testing". So, this should not be an issue, however, if really neccesary, one can implement file locking like for serial ports. The result of playing with this module should be an ACPI driver for that machine/family of machines. Now, I realize there are a lot of different types of machines outthere, and a kernel module for each of them is not practical, so we need to think in the future what to implement in kernel in order to make possible user space acpi drivers. But this is another story. Best regards, Paul Ionescu |