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

From: Dave Hansen (haveblue_at_us.ibm.com)
Date: 08/03/04

  • Next message: David Woodhouse: "[PATCH] [1/3] Split pci quirks array to allow separate declarations." 
    To: Alex Williamson <alex.williamson@hp.com>
Date:	Tue, 03 Aug 2004 10:31:11 -0700

    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/

  • Next message: David Woodhouse: "[PATCH] [1/3] Split pci quirks array to allow separate declarations."

    Relevant Pages

    • Re: [PATCH] Shut up about the damn modules already...
      ... the kernel asks for modules which don't ... Is it that userspace applications try to access all ... Maybe userspace and kernel should share knowledge about ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] Shut up about the damn modules already...
      ... I'm wondering why it is that the kernel is asking for non-existing ... Is it that userspace applications try to access all ... Maybe userspace and kernel should share knowledge about ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [1/1][PATCH] nproc v2: netlink access to /proc information
      ... > The presumed wrong assumptions underlying broken tools of the future ... > making it easy to write correct applications (or in fixing broken apps ... knowledge of the CONFIG_MMU usage models and/or whatever userspace ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: User space out of memory approach
      ... > userspace provided candidate list. ... > instead of fixing the real problem is a real interesting engineering ... that after the source of trouble is fixed it is worth to ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] Filesystem linking protections
      ... > has broken atd and courier in the past. ... > or O_EXCL so there's work to be done in userspace. ... Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)