[RFC] dev_acpi: device driver for userspace access to ACPI

by **Alex Williamson** » Thu, 05 Aug 2004 02:10:06 GMT

This is by no means ready for release, but I wanted to get a sanity
check. I'm still stuck on this idea that userspace needs access to ACPI
namespace. Manageability apps might use this taking inventory of
devices not exposed by other means, things like X can locate chipset
components that don't live in PCI space, there's even the possibility of
making user space drivers.

Populating the sysfs tree didn't seem to generate as much interest as
I'd hoped and I don't think it kept with the spirit of sysfs very well.
So, now I present dev_acpi (name suggestions welcome). The link below
is a tarball with a first stab at the driver as well as a simple proof
of concept application. It should build against any 2.6 kernel as long
as you have the include files available. There are no kernel changes
required, thus it doesn't expose anything not already exposed as a
symbol.

The basic concept of operation is that the ioctl operates on the ACPI
path passed into the ioctl call. The ioctl may return the result of the
operation either in the status field of the argument or use that to
indicate the number of bytes available to read(2) for the result. The
header file included describes the input and output for each operation.
If the status field indicates a byte count to read, the calling
application can easily size buffers, and call read(2) on the device file
to get the results. I've also include support for write(2) that could
allow writing arguments for method calls that take input (completely
untested). I've limited some of the output (for instance in GET_NEXT)
to try to only print out standard ACPI objects, but the filter is pretty
simple (objects beginning w/ '_'). I know the completely open interface
from the sysfs implementation scared some people. Non-standard objects
can still be operated on, but you've got to know what to look for.

Many of the ioctls mimic the behavior of the acpi calls that are
already exported. What I have now is only a start at what could be
provided. The sample, proof-of-concept app, is called acpitree. It's
much like the tree app for listing files and directories. It does
evaluate and print _HIDs represented by integers, but that's about it.
Here's some sample output (sorry anyone not using fixed width fonts):

\\
|-- _GPE
|-- _PR_
|-- _SB_
| |-- SBA0
| | |-- _HID (HWP0001)
| | |-- _CID
| | |-- _CRS
| | |-- _INI
| | |-- _UID
| | |-- MI0_
| | | |-- _HID (IPI0001)
| | | |-- _UID
| | | |-- _STA
| | | `-- _CRS
| | |-- PCI0
| | | |-- _UID
| | | |-- _STA
| | | |-- _BBN
| | | |-- _HID (HWP0002)
| | | |-- _CID
| | | |-- _PRT
...

\\
|-- _GPE
|-- _PR_
|-- _SB_
| |-- _INI
| |-- C00C
| | |-- _HID (PNP0C01)
| | `-- _CRS
| |-- C046
| | |-- _HID (PNP0A03)
| | |-- _ADR
| | |-- C047
| | | |-- _ADR
| | | |-- C0D1
| | | | |-- _ADR
| | | | |-- _REG
| | | | |-- _S3D
| | | | |-- _S4D
| | | | |-- _DOS
| | | | |-- C0DD
| | | | | |-- _ADR
...

You can find the driver and sample app here:

http://free.linux.hp.com/~awilliam/acpi/dev_acpi/dev_acpi-20040803.tar.bz2

There's a brutally short README there. Caveat: the driver is hardcoded
to use an experimental major number, you'll have to mknod it, see the
README.

Please try it out, let me know if

by **Dave Hansen** » Thu, 05 Aug 2004 02:40:08 GMT



The only thing that worries me about a patch like this is that it
encourages people to write arch-specific tools that have no chance of
working on multiple platforms.  

Right now, on ppc64, we have a system for making direct calls into the
firmware, as well as a copy of the firmware's device-tree exported to
userspace.  This means that we have userspace applications that do very
generic things like counting CPUs, or activating memory in very
arch-specific ways.  

Creating more of these interfaces encourages more of these arch-specific
applications, and what we end up with are lots of tools that only work
on Intel platforms or IBM ppc, but not Linux in general.

So, what kinds of generic, arch-independent interfaces should we
implement in the kernel that would reduce the need for something like
your driver?

-- Dave


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/

by **Alex Williamson** » Thu, 05 Aug 2004 03:30:06 GMT





   I agree with your intent, but I'm not sure a common kernel interface
is feasible or desired.  This driver would be much more useful if it was
cleverly abstracted by a userspace library.  Should we try to make the
common layer be the library interface?  Obviously the more similar the
kernel interface, the easier, but I'm not ready to sign-up to architect
a generic interface.

   The ACPI interface could be used to do everything from switching a
laptop display between the interfaces to listing and configuring/de-
configuring specific pieces of hardware.  There will be a set of
functionality that's common across multiple interfaces, but I don't want
to prevent the usage that is very specific to the underlying
implementation.

	Alex  

-- 
Alex Williamson                             HP Linux & Open Source Lab

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/

by **Dave Hansen** » Thu, 05 Aug 2004 03:40:13 GMT





Instead of architecting a generic interface, might you simply exclude
access from your driver to things that already have generic interfaces? 
I think there are things that we exclude from /proc/device-tree on ppc64
because there's a generic equivalent elsewhere.  


There are certainly some very platform-specific things that obviously
need to be done with direct access to the firmware, and that we don't
want to pollute the kernel with.  Parsing some of the firmware error
logs on ppc64 comes to mind.  You just need to be *very* careful with
the application authors because it's such a big gun :)

-- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/

by **Alex Williamson** » Thu, 05 Aug 2004 06:10:06 GMT




   The access interfaces I'm exposing are pretty simple building block
type features.  It's a toolset to poke at namespace, not a predefined
set of device specific functions.  I'm sure you can mix them all
together and duplicate something that already exists, but trying to
kludge in limitations sounds futile and would reduce the usefulness of
the entire interface.  Besides, given a choice, I kinda doubt people are
going to choose to implement something that requires them to know about
ACPI ;^)


   This is certainly a big gun, but in the software world, I'd rather
have a big gun available than no gun at all.  Thanks for the comments,

	Alex

-- 
Alex Williamson                             HP Linux & Open Source Lab

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/

by **Greg KH** » Fri, 06 Aug 2004 14:10:08 GMT



I'm sorry if I didn't speak up at the time, but I still think that your
sysfs patches were the right way to go.  Why do you think they don't
keep with the spirit of sysfs?  Do you have a pointer to your last
patch that exported the acpi table info through sysfs?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to  XXXX@XXXXX.COM 
More majordomo info at   http://www.**--****.com/ 
Please read the FAQ at   http://www.**--****.com/

by **Alex Williamson** » Sat, 07 Aug 2004 01:00:15 GMT

n Wed, 2004-08-04 at 21:36 -0700, Greg KH wrote:

The sysfs patch definitely has a higher coolness factor than the
device file approach. For the most part, the functionality is the same,
so I'm happy to go either way. The kludgy part of the sysfs patch is
the way it's kind of hacking an ioctl interface into the read()/write()
interface available. A read of an object file can return various things
based on what's been written. The same is true of the device file
patch, but the device file patch is far less invasive and ends up being
a nice standalone module. I had to tweak some things in sysfs to get it
to behave the way I wanted (like add some backing store), which made me
start thinking perhaps I should do it another way. I toyed with the
idea of actually making an acpifs, but I couldn't come up with a big
enough win over the sysfs approach to go down that path.

If the sysfs version isn't making too many people cringe, I'd prefer
to pursue that direction. Here's a pointer to the last version I
posted:

http://marc.theaimsgroup.com/?l=linux-kernel&m=108239031314885&w=2

I also attached the latest version I have below, it's newer, but still
dated from April. I believe it still applies and works. let me know if
you think it has a chance. Thanks,

Alex

--
Alex Williamson HP Linux & Open Source Lab

drivers/acpi/scan.c | 661 +++++++++++++++++++++++++++++++++++++++-
drivers/base/firmware_class.c | 8
drivers/i2c/chips/eeprom.c | 3
drivers/pci/pci-sysfs.c | 6
drivers/scsi/qla2xxx/qla_os.c | 32 -
drivers/video/aty/radeon_base.c | 6
drivers/zorro/zorro-sysfs.c | 4
fs/sysfs/bin.c | 17 -
include/linux/sysfs.h | 8
9 files changed, 711 insertions(+), 34 deletions(-)

===== drivers/acpi/scan.c 1.22 vs edited =====
--- 1.22/drivers/acpi/scan.c Tue Feb 3 22:29:19 2004
+++ edited/drivers/acpi/scan.c Mon Apr 26 22:11:02 2004
@@ -7,6 +7,7 @@

#include <acpi/acpi_drivers.h>
#include <acpi/acinterp.h> /* for acpi_ex_eisa_id_to_string() */
+#include <acpi/acnamesp.h> /* for acpi_ns_map_handle_to_node() */

#define _COMPONENT ACPI_BUS_COMPONENT
@@ -25,6 +26,662 @@
static LIST_HEAD(acpi_device_list);
static spinlock_t acpi_device_lock = SPIN_LOCK_UNLOCKED;

+static LIST_HEAD(acpi_bin_file_list);
+static spinlock_t acpi_bin_file_lock = SPIN_LOCK_UNLOCKED;
+
+struct acpi_bin_files {
+ struct list_head list;
+ struct bin_attribute *bin_attrib;
+ u32 use_count;
+};
+
+struct acpi_private_data {
+ char buf[PAGE_SIZE];
+ size_t write_len;
+ size_t read_len;
+ char *write_buf;
+ char *read_buf;
+};
+
+#define to_acpi_device(n) container_of(n, struct acpi_device, kobj)
+#define to_bin_attr(n) container_of(n, struct bin_attribute, attr)
+
+static ssize_t
+acpi_device_write_raw(
+ struct kobject *kobj,
+ struct attribute *attr,
+ char *buf,
+ loff_t off,
+ size_t length)
+{
+ struct acpi_private_data *data = (struct acpi_private_data *)buf;
+ char *new_buf;
+ size_t new_size;
+
+ /* Writing always clears anything left in the read buffer */
+ if (data->read_len) {
+ acpi_os_free(data->read_buf);
+ data->read_len = 0;
+ }
+
+ /* Allow of multiple writes to build up a buffer */
+ new_size = max(data->write_len, (size_t)(off + length));
+ new_buf = kmalloc(new_size, GFP_KE

[RFC] dev_acpi: device driver for userspace access to ACPI

[RFC] dev_acpi: device driver for userspace access to ACPI

Jump to:

Next

[RFC] dev_acpi: device driver for userspace access to ACPI

Re: [RFC] dev_acpi: device driver for userspace access to ACPI

Re: [RFC] dev_acpi: device driver for userspace access to ACPI

Re: [RFC] dev_acpi: device driver for userspace access to ACPI

Re: [RFC] dev_acpi: device driver for userspace access to ACPI

Re: [RFC] dev_acpi: device driver for userspace access to ACPI

Re: [RFC] dev_acpi: device driver for userspace access to ACPI

Similar Threads:

Who is online