From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [RFC] dev_acpi: device driver for userspace access to ACPI Date: Tue, 03 Aug 2004 12:17:29 -0600 Sender: linux-kernel-owner@vger.kernel.org Message-ID: <1091557050.4981.135.camel@tdi> References: <1091552426.4981.103.camel@tdi> <1091554271.27397.5327.camel@nighthawk> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1091554271.27397.5327.camel@nighthawk> To: Dave Hansen Cc: acpi-devel@lists.sourceforge.net, Linux Kernel Mailing List List-Id: linux-acpi@vger.kernel.org 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