generic testing ACPI module
Hi all,
I have this idea and I want your comments about it.
I think it would be nice and usefull to have a generic acpi testing module like other testing modules in kernel (scsi and pci hotplug just came to my mind, but maybe there are some others too).
The purpose is this:
A lot of vendors have different acpi devices that can be controlable with acpi, and can send notification, but they are not universal available on all platforms and usualy differ from vendor to vendor.
For instance, I have an IBM T40 which generate ACPI notification when I want to hotswap the CDROM with a DVD or some other device in the lateral bay. It would be nice if I would receive via acpid such notifications to be able to react acordingly like hdparm -U and tell udev to remove the /udev/hdc file if is necessary, or just rescan the ide bus (idectl 1 rescan).
Other example is when I want to execute arbitrary methods exported by ACPI like I have for instance for sound volume/mute, wireless on/off and other methods.
It is not practical to write a driver for each device outhere just for testing what works and if works, but we could have instead a generic way to map some methods to some functions, and install events receivers for some notify events.
A lot of info about one ACPI system can be gathered by compiling acpi with debug info and just
echo 0x10 > /proc/acpi/debug_level
echo 0x1f > /proc/acpi/debug_layer
This way we can test ourselves what can be done with ACPI, and we can speed the development process.
Moreover, if this generic interface is made by someone who knows well the ACPI implementation in kernel, then we have the chance that it will not introduce more bugs than a driver for a specific vendor/platform which could be made by people with access to that hardware, but not necessary experts in kernel coding (like myself).
The proposition is this:
A module that exports some files in let say /proc/acpi/testing/ directory.
One of the files could be a file where we can insert the full path name of a method we want to run, and after that the driver will make that full path another file in /proc/acpi/testing/ and when we access that file, we actualy run the acpi method.
Example:
echo \_SB_.PCI0.LPC_.EC__._Q13 > /proc/acpi/testing/new_method and a new file with the name \_SB_.PCI0.LPC_.EC__._Q13 is created in /proc/acpi/testing/ directory. When we cat this new file, we'll get the resut of executing that method.
Another file could be a file where we can insert the name/pnpid/node of a device we want to receive notifies from.
Example:
echo MSTR > /proc/acpi/testing/new_system_notify, and when this device receives a system notify it will pass this to acpid.
or:
echo dfee6f28 > /proc/acpi/testing/new_system_notify_node and when this node receives a system notify it will pass this to acpid.
or
echo MSTR > /proc/acpi/testing/new_device_notify, and when this device receives a "device notify" it will pass this to acpid.
I want to hear some opinions about this idea, if this could be usefull for other people too, or is just my imagination that says this. And how feasible is to implement it. I think it should not be too hard for someone with knowledge of acpi subsystem in kernel. Should be about the size of AC module.
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 13 lines · Paul Ionescu
I have this idea and I want your comments about it.
I think it would be nice and usefull to have a generic acpi testing module like other testing modules in kernel (scsi and pci hotplug just came to my mind, but maybe there are some others too).The proposition is this:
A module that exports some files in let say/proc/acpi/testing/directory.
One of the files could be a file where we can insert the full path name of a method we want to run, and after that the driver will make that full path another file in/proc/acpi/testing/and when we access that file, we actualy run the acpi method.
Quoted 5 lines
Example:
echo \_SB_.PCI0.LPC_.EC__._Q13 >/proc/acpi/testing/new_methodand a new file with the name \_SB_.PCI0.LPC_.EC__._Q13 is created in/proc/acpi/testing/directory. When we cat this new file, we'll get the resut of executing that method.
There's actually something much better that could be done. Look in /sys/firmware/acpi/. There's no files created in this hierarchy currently. What we should do is create a file for each method. Reading from it should execute that method and return the result. This is useful in so many ways, it's not even funny.
Signature · 13 lines
"Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
A message that is not in the archive (sent off-list or not yet received): 20040311211005.GM2148-+pPCBgu9SkPzIGdyhVEDUDl5KyyQGfY2kSSpQ9I8OhVaa/[email protected]
Quoted 5 lines · Matthew Wilcox
There's actually something much better that could be done. Look in
/sys/firmware/acpi/. There's no files created in this hierarchy currently. What we should do is create a file for each method. Reading from it should execute that method and return the result. This is useful in so many ways, it's not even funny.
Hi Matthew,
Yes, your remark is good.
I was thinking of that too, but I thought it is more difficult to implement it than a single separate module which can be disabled if neccessary(or buggy).
Now that you mentioned it, I preffer your approach, because is more logical and streamlined than the dirty hack I proposed, and I came with the following additions:
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.
Each event capable object/device should have 2 additional files:
"system" and "device", and echo-ing 0 or 1 in this files should install/deinstall a handler for this device for system or device events.
What do you think ?
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 16 lines · Paul Ionescu
Quoted 5 lines · Matthew Wilcox
There's actually something much better that could be done. Look in
/sys/firmware/acpi/. There's no files created in this hierarchy currently. What we should do is create a file for each method. Reading from it should execute that method and return the result. This is useful in so many ways, it's not even funny.Yes, your remark is good.
I was thinking of that too, but I thought it is more difficult to implement it than a single separate module which can be disabled if neccessary(or buggy).
Now that you mentioned it, I preffer your approach, because is more logical and streamlined than the dirty hack I proposed, and I came with the following additions:
Quoted 5 lines
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.
Ugly. Better I guess is to implement an ioctl in order to execute method. At least, that will give you atomic access to that method.
Quoted 4 lines
Each event capable object/device should have 2 additional files:
"system" and "device", and echo-ing 0 or 1 in this files should install/deinstall a handler for this device for system or device events.
No opinion (yet).
Cheers,
Signature · 11 lines
Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Bruno,
Yes, from programing point of view, it may be a little ugly, but it is easy to use without an aditional program, and you see in that hierarchy what methods you have on a specific hardware.
In the ioctl case, we need at least an aditional program to send the ioctl's to the desired device/method, something like hdparm for sending HD* ioctls, and that is not going to appear over night.
This could be in the future, but to get things started, and have people testing various platforms, we need something easy to use, and available a.s.a.p.
For instance, I was playing with your video acpi driver, and I wished I could run some specific methods to test the brigthness and other functions on my T40 laptop which does not implement them as per ACPI 2.0c.
I was unable to do that without reading/understanding video.c and various other acpi stuff, and modifying the module, recompiling, and only then I could test some methods if they work.
This takes time, and not everybody is willing nor able to make/modify an acpi module just to test some acpi methods.
The main reason of proposing this, was to let people test easily various platforms, and this was supposed to be enabled when compiled with debug or a separate option in the kernel anyway.
Your suggestion is good, but it is for general/sane use of acpi, more like for future support for userspace acpi drivers, which is good too. If the burden/manpower to make it as you suggest is not very much different than in my proposal, then yours is better.
If the difference is big, then IMHO we sould consider first the quickest one.
Best regards,
Paul
Quoted 17 lines · Bruno Ducrot
Quoted 8 lines
Yes, your remark is good.
I was thinking of that too, but I thought it is more difficult to implement it than a single separate module which can be disabled if neccessary(or buggy).
Now that you mentioned it, I preffer your approach, because is more logical and streamlined than the dirty hack I proposed, and I came with the following additions:Quoted 5 lines
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.Ugly. Better I guess is to implement an ioctl in order to execute method. At least, that will give you atomic access to that method.
Quoted 8 lines
Quoted 4 lines
Each event capable object/device should have 2 additional files:
"system" and "device", and echo-ing 0 or 1 in this files should install/deinstall a handler for this device for system or device events.No opinion (yet).
Cheers,
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Paul Ionescu
Hi Bruno,
Yes, from programing point of view, it may be a little ugly, but it is easy to use without an aditional program, and you see in that hierarchy what methods you have on a specific hardware.
The problem is that if someone do what you suggest, the patch for is likely not be accepted at least by mainstream kernel developper. I agree though that is much more easy, from user point-of-view, to do what you suggest, but from kernel point-of-view, I doubt it will be really difficult to do that via ioctl.
Signature · 11 lines
Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Bruno Ducrot
The problem is that if someone do what you suggest, the patch for is likely not be accepted at least by mainstream kernel developper. I agree though that is much more easy, from user point-of-view, to do what you suggest, but from kernel point-of-view, I doubt it will be really difficult to do that via ioctl.
sysfs does not support ioctls. case closed.
Signature · 13 lines
"Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
Hi!
Quoted 14 lines
Quoted 14 lines
Quoted 5 lines
There's actually something much better that could be done. Look in
/sys/firmware/acpi/. There's no files created in this hierarchy currently. What we should do is create a file for each method. Reading from it should execute that method and return the result. This is useful in so many ways, it's not even funny.Yes, your remark is good.
I was thinking of that too, but I thought it is more difficult to implement it than a single separate module which can be disabled if neccessary(or buggy).
Now that you mentioned it, I preffer your approach, because is more logical and streamlined than the dirty hack I proposed, and I came with the following additions:
Quoted 5 lines
Quoted 5 lines
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?
Quoted 2 lines
Ugly. Better I guess is to implement an ioctl in order to execute method. At least, that will give you atomic access to that method.
But ioctls are even worse. Why not simply
open METHOD
write PARAMETERS
read RESULTS
close
its slightly more tricky from shell, but doable too...
Pavel
Signature · 9 lines
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
A message that is not in the archive (sent off-list or not yet received): 20040312144241.GA1236-u08AdweFZfgxtPtxi4kahqVXKuFTiq87@public.gmane.org
Quoted 9 lines · Pavel Machek
Hi!
But ioctls are even worse. Why not simply
open METHOD
write PARAMETERS
read RESULTS
close
Because I'm too stupid to thing of your solution, I guess.
Signature · 11 lines
Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi!
Quoted 8 lines
Quoted 6 lines
But ioctls are even worse. Why not simply
open METHOD
write PARAMETERS
read RESULTS
closeBecause I'm too stupid to thing of your solution, I guess.
Well, instead of doing ioctls on special file, you can simply do write syscall (telling driver parameters for the method) then read syscall on same filedescriptor. That is not racy, and it is less hacky then ioctl()
Pavel
Signature · 9 lines
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
A message that is not in the archive (sent off-list or not yet received): 20040312195912.GA2153-u08AdweFZfgxtPtxi4kahqVXKuFTiq87@public.gmane.org
Hi Pavel,
That should be ok.
For the long term, it sounds reasonable to do it this way if kernel developers agree this usage of sysfs filesystem.
I just remembered one discution from last weeks, that files in sysfs have to accept only one value, and output only one value (or something like this).
I don't know if I got it right, but if this is the case, we should either move this tree in /proc/acpi/somewhere, or create some other files under each method like {parm1,parm2,parmN,result1,result2,resultN} depending of what that particular method takes as arguments and values it return.
Some locking mecanism should be used to be sure that only one program is unsing it a a time.
Anyway, this will take time to implement it, but it may have a future. What I am looking for right now, is to have a VERY SMALL module template of an acpi driver for accessing a method with some parameters, and for installing a notify handler on an object in order to receive some events in acpid when that object receives a notify. And it should operate with full path ACPI objects.
I don't even want it to be included in main kernel, it can live at acpi site, like the patch for putting your own DSDT table in kernel.
I am willing to develop one, but I need a small template because I don't know much about acpi in kernel, and I don't really have a lot of free time to learn it.
But if a template would exist, it would be much easyer for me to just modify it to suit my needs.
Quoted 9 lines · Pavel Machek
Hi!
Quoted 7 lines
Quoted 6 lines
But ioctls are even worse. Why not simply
open METHOD
write PARAMETERS
read RESULTS
close
Quoted 7 lines
Quoted 1 line
Because I'm too stupid to thing of your solution, I guess.
Well, instead of doing ioctls on special file, you can simply do write syscall (telling driver parameters for the method) then read syscall on same filedescriptor. That is not racy, and it is less hacky then
ioctl()
Pavel
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
Is it possible to make file executable ? Whe could do somethink like :
$/sys/proc/acpi/methods/QXX param1 param2 param3
Result : r1 r2 r3
$
Quoted 12 lines · On Fri, 12 Mar 2004 18:57:24 +0100 Bruno Ducrot…
Quoted 6 lines · Pavel Machek
Hi!
But ioctls are even worse. Why not simply
open METHOD
write PARAMETERS
read RESULTS
closeBecause I'm too stupid to thing of your solution, I guess.
Signature · 1 line
Bruno Ducrot
Signature · 9 lines
Frederic Leroy Lost in Germany ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
A message that is not in the archive (sent off-list or not yet received): 20040312222244.5f523037.geekcelibataire-GANU6spQydw@public.gmane.org
Quoted 4 lines · On Pá 12-03-04 22:22:44, [email protected] wrote:
Is it possible to make file executable ? Whe could do somethink like :
$/sys/proc/acpi/methods/QXX param1 param2 param3
Result : r1 r2 r3
No.
Pavel
Signature · 9 lines
When do you have a heart between your knees? [Johanka's followup: and *two* hearts?] ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
Quoted 8 lines · Pavel Machek
Quoted 5 lines
Quoted 5 lines
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
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi!
Quoted 5 lines
Quoted 2 lines
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,
Well, if your goal is quick hack, then you should not bother with requesting comments ([RFC]) and just post a patch...
Signature · 9 lines
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
A message that is not in the archive (sent off-list or not yet received): 20040313140059.GA3764-u08AdweFZfgxtPtxi4kahqVXKuFTiq87@public.gmane.org
Hi Pavel,
The quick hack is for beginnig with something, which I think should evolve in some interface to control the ACPI from userspace. Will this be the way of making specific vendor ACPI drivers, or the kernel based modules approach ?
We don't know yet, but if is not critical, kernel guys tend to push things out of kernel space. And sometimes they are right. So I considered the RFC for both quick hack and for the evolving interface.
If I was wrong, please excuse my wasting of your time.
Best regards,
Quoted 10 lines · Pavel Machek
Hi!
Quoted 5 lines
Quoted 2 lines
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,
Well, if your goal is quick hack, then you should not bother with requesting comments ([RFC]) and just post a patch...
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
Quoted 7 lines · Pavel Machek
But ioctls are even worse. Why not simply
open METHOD
write PARAMETERS
read RESULTS
closeits slightly more tricky from shell, but doable too...
I'll be happy to provide a perl script which does this and hands out the results in a way useable for shell junkies.
Not everything should be done from a shell ;-)
Signature · 9 lines
Stefan Seyfried ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click