* Greg KH <greg@xxxxxxxxx>: > > Ok, again, I want to see the IBM people sign off on this, after > testing on all of their machines, before I'll consider this, as > I know the IBM acpi tables are "odd". Who would be a good contact at IBM to get some eyes / machine time on this? > Also, how about Dell machines? I know they are probably not > expecting this information to show up and who knows if the > numbering of their slots match up with their physical diagrams Who would be a good contact at Dell for the same? I don't have as much experience with oddball firmware from various vendors as others on this list, but given the rather stable definition of _SUN in the ACPI spec, I'd be surprised to see vendors abusing that method. [I fully accept the possibility that I'm just naive ;)] More likely, a vendor will do what the HP Proliant folks did, that being simply omitting a _SUN method altogether. One more thought on that -- at *worst* my patch series will do no worse than the status quo of what the acpiphp module is doing today. That module walks through the namespace looking for _SUN methods, and when it finds them, it creates an entry in exactly the same spot (/sys/bus/pci/slots/N) that my patch series does. What this series adds beyond acpiphp is adding entries for slots that aren't hotpluggable. > IBM sells a program that does this for server rooms. It's > probably part of some Tivoli package somewhere, sorry I don't > remember the name. I did see it working many years ago and it > required no kernel changes at all to work properly. Like I said in an earlier email, HP ia64 systems will require a kernel change to get this information. Whether it comes via a generic ACPI access layer like dev_acpi, or something like this patch series, the kernel will still get touched. Thanks. /ac - 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
