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

[Alex Williamson <alex.williamson@hp.com>]

On Tue, 2004-08-03 at 10:31 -0700, Dave Hansen wrote:
> On Tue, 2004-08-03 at 10:00, Alex Williamson wrote:
> >    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.
> 
> 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?

   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