[ACPI] PATCH-ACPI based CPU hotplug[2/6]-ACPI Eject interfacesupport

   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.


   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

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

   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

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