[rfc] generic testing ACPI module

[rfc] generic testing ACPI module

[Paul Ionescu]

Hello to all acpi developers,

I have an 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

[rfc] generic testing ACPI module

[Paul Ionescu]

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

Re: [rfc] generic testing ACPI module

[Matthew Wilcox]

On Thu, Mar 11, 2004 at 10:53:31PM +0200, Paul Ionescu wrote:
> 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.
> 
> 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.

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.

-- 
"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

Re: [rfc] generic testing ACPI module

[Paul Ionescu]

On Thu, 2004-03-11 at 23:10, Matthew Wilcox wrote:

> 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

Re: [rfc] generic testing ACPI module

[Bruno Ducrot]

On Thu, Mar 11, 2004 at 11:48:14PM +0200, Paul Ionescu wrote:
> On Thu, 2004-03-11 at 23:10, Matthew Wilcox wrote:
> 
> > 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:
> 
> 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.

> 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,

-- 
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

Re: [rfc] generic testing ACPI module

[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.
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




On Fri, 2004-03-12 at 00:50, Bruno Ducrot wrote:
> > 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.
> 
> 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.
> 
> > 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

Re: [rfc] generic testing ACPI module

[Bruno Ducrot]

On Fri, Mar 12, 2004 at 07:30:35AM +0200, Paul Ionescu wrote:
> 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.

-- 
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

Re: [rfc] generic testing ACPI module

[Matthew Wilcox]

On Fri, Mar 12, 2004 at 11:29:21AM +0100, Bruno Ducrot wrote:
> 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.

-- 
"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

Re: [rfc] generic testing ACPI module

[Pavel Machek]

Hi!

> > > 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:
> > 
> > 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?

> 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
-- 
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

Re: [rfc] generic testing ACPI module

[Bruno Ducrot]

On Fri, Mar 12, 2004 at 03:42:41PM +0100, Pavel Machek wrote:
> 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.

-- 
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

Re: [rfc] generic testing ACPI module

[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.

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
-- 
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

Re: [rfc] generic testing ACPI module

[geekcelibataire-GANU6spQydw]

Is it possible to make file executable ? Whe could do somethink like :

$/sys/proc/acpi/methods/QXX param1 param2 param3 
Result : r1 r2 r3
$

On Fri, 12 Mar 2004 18:57:24 +0100
Bruno Ducrot <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> wrote:

> On Fri, Mar 12, 2004 at 03:42:41PM +0100, Pavel Machek wrote:
> > 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.
> 
> -- 
> Bruno Ducrot

-- 
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

Re: [rfc] generic testing ACPI module

[Pavel Machek]

On Pá 12-03-04 22:22:44, geekcelibataire-GANU6spQydw@public.gmane.org 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
-- 
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_id\x1470&alloc_id638&op=click

Re: [rfc] generic testing ACPI module

[Paul Ionescu]

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.




On Fri, 2004-03-12 at 21:59, Pavel Machek wrote:
> 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.
> 
> 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

Re: [rfc] generic testing ACPI module

[Paul Ionescu]

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



-------------------------------------------------------
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

Re: [rfc] generic testing ACPI module

[Pavel Machek]

Hi!

> > 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...
-- 
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

Re: [rfc] generic testing ACPI module

[Paul Ionescu]

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,

On Sat, 2004-03-13 at 16:00, Pavel Machek wrote:
> Hi!
> 
> > > 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

Re: [rfc] generic testing ACPI module

[Stefan Seyfried]

On Fri, Mar 12, 2004 at 03:42:41PM +0100, Pavel Machek wrote:

> But ioctls are even worse. Why not simply
> 	open METHOD
> 	write PARAMETERS
> 	read RESULTS
> 	close
> 
> its 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 ;-)
-- 
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