lkml.org 
[lkml]   [2004]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] dev_acpi: device driver for userspace access to ACPI
From
Date
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?

-- Dave


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.204 / U:1.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site