On Tue, 13 Nov 2007 12:26:32 -0800 Greg KH <greg@xxxxxxxxx> wrote: > On Tue, Nov 13, 2007 at 01:21:54PM -0700, Alex Chiang wrote: > > * Greg KH <greg@xxxxxxxxx>: > > > 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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
