Re: Re: [PATCH] filling in ACPI method access via sysfs

Re: Re: [PATCH] filling in ACPI method access via sysfs

[Paul Ionescu]

Hi Alex,

I tried to play with your new patch. I am able now to run arbitrary
parameterless methods. I have some problems accessing the methods
requiring parameters, or giving results.

I did an "echo 1 > /sys/.../DOCK/_DCK " but nothing happened, and I have
tried also to cat it but I got "cat: Read error: No such device"

And I did an "cat /sys/.../_STA" and I receive 
cat: Read error: No such device
Do I miss something ?

Thanks,
Paul


On Sun, 2004-04-11 at 16:29, Alex Williamson wrote: 
>> 
>> It seems unintuitive that you have to read the file for the method to
>> take effect.  How about having the write function invoke the method and
>> (if there is a result) store it for later read-back via the read function?
>> It should be discarded on close, of course.  A read() on a file with
>> no stored result should invoke the ACPI method (on the assumption this
>> is a parameter-less method) and return the result directly.  Closing a
>> file should discard any result from the method.
>
>  How's this?  It behaves the way you described, but might be doing
> some questionable things with the buffer to get there.  Is there a
> better place to store the return data than back into the buf passed to
> write() (aka file->private_data)?  Without adding callbacks to
> open/close, I'm not sure how else we can dispose of the results on
> close.  Thanks,
>
>	Alex



-------------------------------------------------------
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: Re: [PATCH] filling in ACPI method access via sysfs

[Alex Williamson]

On Tue, 2004-04-13 at 16:15, Paul Ionescu wrote:
> Hi Alex,
> 
> I tried to play with your new patch. I am able now to run arbitrary
> parameterless methods. I have some problems accessing the methods
> requiring parameters, or giving results.
> 
> I did an "echo 1 > /sys/.../DOCK/_DCK " but nothing happened, and I have
> tried also to cat it but I got "cat: Read error: No such device"
> 
> And I did an "cat /sys/.../_STA" and I receive 
> cat: Read error: No such device
> Do I miss something ?
> 

   Yeah, the latest iteration only supports read/write to the files, I
removed support for the show/store ops.  So, you need a program/script
that open()s the file, write()s arguments (if any), read()s the results,
and close()s the file.  Thanks,

	Alex

> 
> On Sun, 2004-04-11 at 16:29, Alex Williamson wrote: 
> >> 
> >> It seems unintuitive that you have to read the file for the method to
> >> take effect.  How about having the write function invoke the method and
> >> (if there is a result) store it for later read-back via the read function?
> >> It should be discarded on close, of course.  A read() on a file with
> >> no stored result should invoke the ACPI method (on the assumption this
> >> is a parameter-less method) and return the result directly.  Closing a
> >> file should discard any result from the method.
> >
> >  How's this?  It behaves the way you described, but might be doing
> > some questionable things with the buffer to get there.  Is there a
> > better place to store the return data than back into the buf passed to
> > write() (aka file->private_data)?  Without adding callbacks to
> > open/close, I'm not sure how else we can dispose of the results on
> > close.  Thanks,
> >
> >	Alex
-- 
Alex Williamson                             HP Linux & Open Source Lab



-------------------------------------------------------
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: Re: [PATCH] filling in ACPI method access via sysfs

[Paul Ionescu]

Hi Alex,

Your new patch for acpi sysfs is looking good, we have access now to all methods of DSDT and can do some userspace utilities (drivers).
Now, what we need at kernel level, IMHO, is to be able to attach a generic notify handler to the devices exported.
For instance we can have another file in sysfs like NOTIFY or something, and when activated (perhaps an echo 1 > NOTIFY should do), 
that device will be able to handle a notify. 
The basic handling can be just sending an message in /proc/acpi/event containing full device name and notify value.
Then acpid should do the rest if necessary.


Thanks,
Paul


On Sun, 2004-04-11 at 16:29, Alex Williamson wrote: 
>> 
>> It seems unintuitive that you have to read the file for the method to
>> take effect.  How about having the write function invoke the method and
>> (if there is a result) store it for later read-back via the read function?
>> It should be discarded on close, of course.  A read() on a file with
>> no stored result should invoke the ACPI method (on the assumption this
>> is a parameter-less method) and return the result directly.  Closing a
>> file should discard any result from the method.
>
>  How's this?  It behaves the way you described, but might be doing
> some questionable things with the buffer to get there.  Is there a
> better place to store the return data than back into the buf passed to
> write() (aka file->private_data)?  Without adding callbacks to
> open/close, I'm not sure how else we can dispose of the results on
> close.  Thanks,
>
>	Alex



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