Re: [PATCH 0/5][RFC] Physical PCI slot objects

[Greg KH <greg@kroah.com>]

On Tue, Nov 13, 2007 at 01:36:45PM -0700, Alex Chiang wrote:
> * Greg KH <greg@kroah.com>:
> > 
> > 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?

The current 2.4 pci hotplug maintainer?  :)

> > 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?

Matt has already spoken up for this...

> 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.

The acpiphp module is not loaded on zillions of non-pci-hotplug
machines...

> What this series adds beyond acpiphp is adding entries for slots
> that aren't hotpluggable.

How are you going to ensure that the userspace programs that use those
sysfs files are not going to break into tiny pieces now that you have
extended this to show all pci slots?

> > 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.

And like I said, I'm pretty sure you don't need to touch the kernel
today as there are people doing this just fine from userspace without
any kernel changes needed :)

thanks,

greg k-h