lkml.org 
[lkml]   [2007]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/5][RFC] Physical PCI slot objects
    On Tue, 13 Nov 2007 12:26:32 -0800
    Greg KH <greg@kroah.com> wrote:

    > On Tue, Nov 13, 2007 at 01:21:54PM -0700, Alex Chiang wrote:
    > > * Greg KH <greg@kroah.com>:
    > > > On Mon, Nov 12, 2007 at 05:08:53PM -0700, Alex Chiang wrote:
    > > > >
    > > > > Recently, Matthew Wilcox sent out the following mail about
    > > > > PCI slots:
    > > > >
    > > > > http://marc.info/?l=linux-pci&m=119432330418980&w=2
    > > > >
    > > > > The following patch series is a rough first cut at
    > > > > implementing the ideas he outlined, namely, that PCI slots
    > > > > are physical objects that we care about, independent of their
    > > > > hotplug capabilities.
    > > >
    > > > Also, some companies already provide userspace tools to get all
    > > > of this information about the different slots in a system and
    > > > what is where, from userspace, no kernel changes are needed.
    > > > So, why add all this extra complexity to the kernel if it is
    > > > not needed?
    > >
    > > On HP ia64 systems, that information is locked away in ACPI, and
    > > there's no easy way to get at it. Alex Williamson tried providing
    > > a generic dev_acpi driver, so that userspace could do whatever
    > > they wanted to with the information:
    > >
    > > http://lkml.org/lkml/2004/8/3/106
    > >
    > > And that effort kinda died. I'm of mixed feelings on that driver,
    > > since it would be really nice to get unfettered access to the
    > > ACPI namespace, but it's pretty dangerous, since any interesting
    > > thing you might want to do is actually a method (aka, it calls
    > > into firmware) and who knows what side effects there might be.
    > >
    > > So from my point of view, if ia64 customers want to know about
    > > the slots they have in their systems, we're gonna have to do
    > > something kernel-intrusive anyhow.
    >
    > Doesn't /sys/firmware/acpi give you raw access to the correct tables
    > already?
    >
    > And isn't there some other tool that dumps the raw ACPI tables? I
    > thought the acpi developers used it all the time when debugging things
    > with users.
    >
    > thanks,
    >
    > greg k-h
    >

    There are - people should take a look at the Intel Linux Firmware Kit
    for an example of how to parse ACPI tables in userspace - the code
    is also GPL'd, so you are free to use it in another GPL application.

    http://www.linuxfirmwarekit.org/download.php#source

    In many DSDTs I've seen, _SUN is hardcoded anyway and can be found
    by reading the DSDT from userspace. This is what the firmwarekit
    does to check for duplicate _SUN in one of it's tests.

    Kristen

    -
    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: 2007-11-14 00:05    [W:4.432 / U:0.248 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site