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 11:34 -0700, Dave Hansen wrote:

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

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 ;^)

> 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 :)

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 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.032 / U:1.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site