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