>> > >
>> > > Hi Anil,
>> > >
>> > > I obviously failed to deliver my idea :) I meant that I
>would like add eject
>> > > attribute (along with maybe status, hid and some others)
>to kobjects in
>> > > /sys/firmware/acpi tree.
>> > >
>> >
>> > Dmitry,
>> >
>> > See the patch I just posted to acpi-devel and lkml (Subject:
>> > [PATCH/RFC] exposing ACPI objects in sysfs). It exposes
>acpi objects as
>> > you describe. Something simple like:
>> >
>> > # cat /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/_EJ0
>> >
>> > Will call the _EJ0 method on the ACPI device. You can
>evaluate eject
>> > dependencies using the _EJD method.
>> >
>> > Alex
>> >
>>
>> Alex,
>>
>> While I think that your patch is very important and should
>be included (maybe
>> if not as is if somebody has some objections but in some
>other form) I see it
>> more like developer's tool. I imagined status, HID, eject
>etc. attributes to
>> be sanitized interface to kernel's data, not necessarily
>causing re-evaluation.
>>
>
>Dmitry,
>
> I imagined the sanitized interfaces would be provided via a
>userspace
>library, similar to how lspci provides a clean interface to all of the
>PCI data. An "lsacpi" tool could extract the information into
>something
>more like you suggest. If you have objects exposed as human
>readable/writable files, I think you'll quickly end up with a _STA
>driver, _HID driver, _CID driver, _ADR driver, _UID driver,
>_EJx driver,
>etc, etc, etc... I don't think we want that kind of bloat in
>the kernel
>(that's what userspace is for ;^). Providing a solid, direct interface
>to ACPI methods in the kernel seems like the most flexible, powerful
>interface IMHO. Thanks,
>
> Alex
>
>> So it could be like this:
>>
>> /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/status
>> /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/removable
>> /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/lockable
>> ..
>> /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/eject
>>
>> And your raw access to the ACPI methods could reside under raw:
>>
>> /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_STA
>> /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_RNV
>> /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_LCK
>> ..
>> /sys/firmware/acpi/namespace/ACPI/_SB/LSB0/raw/_EJ0
>
This sounds like a good idea. To call the raw AML methods from
User space, just need to solve the problem of argument passing.
But, some AML methods are risky to be called directly from user space,
Not only because the side effect of its execution, but also because
it could trigger potential AML method bug or interpreter bug, or even
architectural defect. All of these headache is due to the AML method
is NOT intended for being used by userspace program.
Thanks,
Luming
> This sounds like a good idea. To call the raw AML methods from
> User space, just need to solve the problem of argument passing.
Solved, the driver I proposed takes an acpi_object_list for passing
arguments to the methods. The kernel-userspace interface replaces the
pointers in these structures with offsets into the buffer (userspace
responsibility to pass in offsets, kernel responsibility to pass back
offsets). I've modified the sysfs bin_file to allow ACPI object files
to have backing store on a per-open basis. There are special commands
that can be written to the ACPI object files to evaluate attributes of
them. Perhaps these could include some of the things we're looking for
here.
> But, some AML methods are risky to be called directly from user space,
> Not only because the side effect of its execution, but also because
> it could trigger potential AML method bug or interpreter bug, or even
> architectural defect. All of these headache is due to the AML method
> is NOT intended for being used by userspace program.
I've made an attempt to hide the most obvious dangerous methods, but
undoubtedly, there will be some. Why are we any more likely to hit an
AML method bug, interpreter bug or architectural bug by having a
userspace interface? Because we can more easily exercise the code? It
calls the same code paths a driver could. The driver I propose for this
task does not require any additionally low-level ACPI functions to be
exported. I think it's too much complexity in the kernel to abstract
every possible bit of data someone might find useful into kernel
drivers.
Take a simple case of looking for a device with a specific _HID value
and wanting the _CRS data for it. The _HID value part is easy, but add
all the smarts to parse the _CRS data into something human readable, and
code bloat gets huge. Then throw in the problem of parsing vendor data
types, and you'll never get finished. This is a real example. The zx1
ia64 chipset can only be discovered through ACPI namespace. It's
physical address is saved in a vendor resource descriptor. We currently
have to do some pretty ugly stuff in X to take a reasonable guess a what
chipset we're using. We need some mechanism to get this data in
userspace, and I don't see an approach better than offloading the
complicated data parsing into userspace. Adding only the methods needed
to solve a specific problem sounds like a maintainability nightmare.
Thanks,
Alex
On Mon, Sep 20, 2004 at 09:02:18PM -0600, Alex Williamson wrote:
> > But, some AML methods are risky to be called directly from user space,
> > Not only because the side effect of its execution, but also because
> > it could trigger potential AML method bug or interpreter bug, or even
> > architectural defect. All of these headache is due to the AML method
> > is NOT intended for being used by userspace program.
>
> I've made an attempt to hide the most obvious dangerous methods, but
> undoubtedly, there will be some. Why are we any more likely to hit an
> AML method bug, interpreter bug or architectural bug by having a
> userspace interface?
As long as the userspace interfaces are only available to the root
filesystem, I'm not sure it's worth it to hide any of the methods.
It's added complexity, and in any case, root can do untold amounts of
damage by writing to /dev/mem, trying to upload firmware to IDE
drives, etc., etc., etc.
As you have pointed out, if there are bugs in the interpret, et. al,
it is better to expose them sooner rather than to stick our heads in
the sand and pretend they don't exist.
- Ted
On Tue, 2004-09-21 at 13:25 -0400, Theodore Ts'o wrote:
> On Mon, Sep 20, 2004 at 09:02:18PM -0600, Alex Williamson wrote:
> > > But, some AML methods are risky to be called directly from user space,
> > > Not only because the side effect of its execution, but also because
> > > it could trigger potential AML method bug or interpreter bug, or even
> > > architectural defect. All of these headache is due to the AML method
> > > is NOT intended for being used by userspace program.
> >
> > I've made an attempt to hide the most obvious dangerous methods, but
> > undoubtedly, there will be some. Why are we any more likely to hit an
> > AML method bug, interpreter bug or architectural bug by having a
> > userspace interface?
>
> As long as the userspace interfaces are only available to the root
> filesystem, I'm not sure it's worth it to hide any of the methods.
> It's added complexity, and in any case, root can do untold amounts of
> damage by writing to /dev/mem, trying to upload firmware to IDE
> drives, etc., etc., etc.
Yes, very true. I think the difference is that in my current
implementation, objects are evaluated on read. This makes it terribly
easy to do the wrong thing "Hmm, I wonder what that file does... oops".
Evaluating on write would set the bar a little higher, but still has
some of the same issues. In theory, I definitely agree, the interface
shouldn't need to hide anything. (I'm sure there are ACPI firmware
folks frightened by that idea) Thanks,
Alex
--
Alex Williamson HP Linux & Open Source Lab