[lm-sensors] Interface to PCI device list

[lm-sensors] Interface to PCI device list

[Jean Delvare]

Hi Greg,

Currently, the sensors-detect script uses /proc/bus/pci/devices (file)
to get a list of the PCI devices on the system. As this file doesn't
contain PCI class data, and I need it, I was looking for an
alternative. For 2.6 kernels, /sys/bus/pci/devices (directory) looks
like the right place to look at. This raises a few questions, which I
hope you can answer:

1* /proc/bus/pci/devices doesn't appear to contain PCI domain
information. I guess it only lists the devices on domain 0000, and
would miss devices on multi-domain machines?

2* Since which kernel version does /sys/bus/pci/devices look like the
way it is right now? Did the device IDs always include the PCI domain?
If it's stable since 2.6.0, I could use it in sensors-detect.

3* Will /sys/bus/pci/devices go away eventually?

Thanks,
-- 
Jean Delvare

[lm-sensors] Interface to PCI device list

[Greg KH]

On Sat, Sep 02, 2006 at 04:42:48PM +0200, Jean Delvare wrote:
> Hi Greg,
> 
> Currently, the sensors-detect script uses /proc/bus/pci/devices (file)
> to get a list of the PCI devices on the system. As this file doesn't
> contain PCI class data, and I need it, I was looking for an
> alternative. For 2.6 kernels, /sys/bus/pci/devices (directory) looks
> like the right place to look at. This raises a few questions, which I
> hope you can answer:
> 
> 1* /proc/bus/pci/devices doesn't appear to contain PCI domain
> information. I guess it only lists the devices on domain 0000, and
> would miss devices on multi-domain machines?

Yes, it doesn't contain domain info on x86 boxes.  Not sure about bigger
ones like ia64 or ppc64.

> 2* Since which kernel version does /sys/bus/pci/devices look like the
> way it is right now? Did the device IDs always include the PCI domain?
> If it's stable since 2.6.0, I could use it in sensors-detect.

/sys/bus/pci/devices has always been there since 2.6.0.  I don't know
for sure about the format of the pci bus ids, but I think they have been
the same since that time too.

> 3* Will /sys/bus/pci/devices go away eventually?

No, that is the proper way to easily enumerate all PCI devices in the
system.  X is also switching over to use this, so it can not go away any
time in the next couple of years, unless something really wrong is found
with it (and something new would have to be created for it, which I
don't see happening...)

Hope this helps,

greg k-h

[lm-sensors] Interface to PCI device list

[Jean Delvare]

Hi Greg,

> > 1* /proc/bus/pci/devices doesn't appear to contain PCI domain
> > information. I guess it only lists the devices on domain 0000, and
> > would miss devices on multi-domain machines?
> 
> Yes, it doesn't contain domain info on x86 boxes.  Not sure about bigger
> ones like ia64 or ppc64.

I just checked on two ia64 boxes, one with domains and one without, and
the info doesn't appear to be in /proc/bus/pci/devices (same column
count, none of which matched the domains). The difference is in the
names of the directories below /proc/bus/pci.

On the multi-domain ia64 machine:

dr-xr-xr-x 2 root root 0 2006-09-02 22:08 0001:00
dr-xr-xr-x 2 root root 0 2006-09-02 22:08 0002:00
dr-xr-xr-x 2 root root 0 2006-09-02 22:08 0003:00
dr-xr-xr-x 2 root root 0 2006-09-02 22:08 0004:00
dr-xr-xr-x 2 root root 0 2006-09-02 22:08 0005:00
dr-xr-xr-x 2 root root 0 2006-09-02 22:08 0006:00
dr-xr-xr-x 2 root root 0 2006-09-02 22:08 0011:00
dr-xr-xr-x 2 root root 0 2006-09-02 22:08 0012:00
dr-xr-xr-x 2 root root 0 2006-09-02 22:08 0013:00
dr-xr-xr-x 2 root root 0 2006-09-02 22:08 0013:01
dr-xr-xr-x 2 root root 0 2006-09-02 22:08 0014:00
dr-xr-xr-x 2 root root 0 2006-09-02 22:08 0014:01
dr-xr-xr-x 2 root root 0 2006-09-02 22:08 0015:00
dr-xr-xr-x 2 root root 0 2006-09-02 22:08 0015:01
dr-xr-xr-x 2 root root 0 2006-09-02 22:08 0016:00
-r--r--r-- 1 root root 0 2006-09-02 22:08 devices

On another machine:

dr-xr-xr-x  2 root root 0 2006-09-02 22:09 00
dr-xr-xr-x  2 root root 0 2006-09-02 12:31 01
dr-xr-xr-x  2 root root 0 2006-09-02 22:09 02
-r--r--r--  1 root root 0 2006-09-02 22:09 devices

So on the multi-domain machine, the domain is prepended to the bus
number. This is where lspci appears to be taking the information when
told to use /proc. I found that lspci was using /sys/bus/pci/devices by
default on Linux 2.6. It can be forced back to using /proc/bus/pci,
with more or less success depending on the system.

> > 2* Since which kernel version does /sys/bus/pci/devices look like the
> > way it is right now? Did the device IDs always include the PCI domain?
> > If it's stable since 2.6.0, I could use it in sensors-detect.
> 
> /sys/bus/pci/devices has always been there since 2.6.0.  I don't know
> for sure about the format of the pci bus ids, but I think they have been
> the same since that time too.

Good. I checked on 2.6.5 (Suse flavor) and it's indeed the same. And
I think supporting from 2.6.5 is good enough, nobody sane would use a
2.6 kernel older than that these days.

> > 3* Will /sys/bus/pci/devices go away eventually?
> 
> No, that is the proper way to easily enumerate all PCI devices in the
> system.  X is also switching over to use this, so it can not go away any
> time in the next couple of years, unless something really wrong is found
> with it (and something new would have to be created for it, which I
> don't see happening...)

Damn. I thought your answer was a bit strange, until I read my question
again and noticed I had messed up ;) Let me try again:

3B* Will /proc/bus/pci go away eventually?

Of course, I did not expect /sys/bus/pci/devices to go away by the
next 7 years...

> Hope this helps,

Well, now I get to decide what I want to do. I need the PCI class and
this doesn't appear to be easy to get using /proc/bus/pci (you need to
walk through subdirectories, and extract the 3 class bytes from each
binary file.) This seems much easier to get it
from /sys/bus/pci/devices (single directory to get the list, then just
one text file to read to get the class for each device.)

For now my code is a ugly hack reading the device list
from /proc/bus/pci/devices, then for each device the class
from /sys/bus/pci/devices if available. That was the shortest path from
the current code to what I wanted to do, and was good enough for
testing, but I'd be ashamed to commit it as is. The only advantage is
the compatibility with 2.4 kernels.

Thanks,
-- 
Jean Delvare

[lm-sensors] Interface to PCI device list

[Greg KH]

On Sat, Sep 02, 2006 at 10:41:51PM +0200, Jean Delvare wrote:
> So on the multi-domain machine, the domain is prepended to the bus
> number. This is where lspci appears to be taking the information when
> told to use /proc. I found that lspci was using /sys/bus/pci/devices by
> default on Linux 2.6. It can be forced back to using /proc/bus/pci,
> with more or less success depending on the system.

Yes, lspci uses sysfs to get most of it's info these days.

> > > 3* Will /sys/bus/pci/devices go away eventually?
> > 
> > No, that is the proper way to easily enumerate all PCI devices in the
> > system.  X is also switching over to use this, so it can not go away any
> > time in the next couple of years, unless something really wrong is found
> > with it (and something new would have to be created for it, which I
> > don't see happening...)
> 
> Damn. I thought your answer was a bit strange, until I read my question
> again and noticed I had messed up ;) Let me try again:
> 
> 3B* Will /proc/bus/pci go away eventually?
> 
> Of course, I did not expect /sys/bus/pci/devices to go away by the
> next 7 years...

Heh, ok, that makes more sense.

No, I don't have any immediate plans to drop it.  It is messy, and hard
to read, but some tools use it (like X) and the code to generate it is
very tiny.  But who knows, someone might send me a patch once X is
converted over to use sysfs fully :)

> > Hope this helps,
> 
> Well, now I get to decide what I want to do. I need the PCI class and
> this doesn't appear to be easy to get using /proc/bus/pci (you need to
> walk through subdirectories, and extract the 3 class bytes from each
> binary file.)

Which is exactly why we created sysfs :)

> This seems much easier to get it from /sys/bus/pci/devices (single
> directory to get the list, then just one text file to read to get the
> class for each device.)

Yes.

> For now my code is a ugly hack reading the device list
> from /proc/bus/pci/devices, then for each device the class
> from /sys/bus/pci/devices if available. That was the shortest path from
> the current code to what I wanted to do, and was good enough for
> testing, but I'd be ashamed to commit it as is. The only advantage is
> the compatibility with 2.4 kernels.

Ick, who cares about 2.4 anymore :)

I'd recommend using sysfs, and following the rules of walking the tree
and not relying on specific files to be present that might not be in the
future.  Also please be able to handle any directory turning into a
symlink at any point in the future too, but since you aren't messing
with the /sys/class/ directories, I don't think this will be a problem
for you.

If you want, we have some very flexible code in udev to traverse sysfs
and get various things from it.  Feel free to use it, as the license is
the same for both projects (GPL).

thanks,

greg k-h

[lm-sensors] Interface to PCI device list

[Jean Delvare]

Hi Greg,

On Sat, 2 Sep, Greg KH wrote:
> On Sat, Sep 02, 2006 at 10:41:51PM +0200, Jean Delvare wrote:
> > For now my code is a ugly hack reading the device list
> > from /proc/bus/pci/devices, then for each device the class
> > from /sys/bus/pci/devices if available. That was the shortest path from
> > the current code to what I wanted to do, and was good enough for
> > testing, but I'd be ashamed to commit it as is. The only advantage is
> > the compatibility with 2.4 kernels.
> 
> Ick, who cares about 2.4 anymore :)

You'd be surprised. We had many requests to backport drivers from 2.6
to 2.4 for chips which are found only on recent (1 or 2 year old)
motherboards. Of course we can ignore these requests, but at least I'd
avoid breaking common code (like the sensors-detect script) which
worked on 2.4 for years. So I'll leave the old code around.

> I'd recommend using sysfs, and following the rules of walking the tree
> and not relying on specific files to be present that might not be in the
> future.  Also please be able to handle any directory turning into a
> symlink at any point in the future too, but since you aren't messing
> with the /sys/class/ directories, I don't think this will be a problem
> for you.

I don't see how it can be a problem at all, given that symbolic links
are meant to be transparent to applications by design. I know recent
events prove me wrong though :(

My algorithm is simple, I do (pseudocode):

opendir("/sys/bus/pci/devices")
  for each entry that matches %x:%x:%x.%x (or %x:%x.%x, just in case),
    add an element to my list of pci devices
    read attribute file "vendor" and store the value
    read attribute file "device" and store the value
    read attribute file "class" and store the value
closedir("/sys/bus/pci/devices")

Now I admit that the code getting the info from /proc was more compact,
but it misses the domain and the class, and adding them would make the
code MUCH more complex, so I'm not gonna do it.

I attached the real code in case someone wants to take a look and
comment. I'll probably apply it soon if no objections arise.

> If you want, we have some very flexible code in udev to traverse sysfs
> and get various things from it.  Feel free to use it, as the license is
> the same for both projects (GPL).

The code was simple enough that I could write it myself in a few
minutes. And I doubt there's much perl code in udev, is there?

Thanks,
-- 
Jean Delvare
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sensors-detect-sys-pci-bus-devices.patch
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060903/5b6447f6/attachment-0001.pl 

[lm-sensors] Interface to PCI device list

[Jean Delvare]

> > I'd recommend using sysfs, and following the rules of walking the tree
> > and not relying on specific files to be present that might not be in the
> > future.  Also please be able to handle any directory turning into a
> > symlink at any point in the future too, but since you aren't messing
> > with the /sys/class/ directories, I don't think this will be a problem
> > for you.
> 
> I don't see how it can be a problem at all, given that symbolic links
> are meant to be transparent to applications by design. I know recent
> events prove me wrong though :(
> 
> My algorithm is simple, I do (pseudocode):
> 
> opendir("/sys/bus/pci/devices")
>   for each entry that matches %x:%x:%x.%x (or %x:%x.%x, just in case),
>     add an element to my list of pci devices
>     read attribute file "vendor" and store the value
>     read attribute file "device" and store the value
>     read attribute file "class" and store the value
> closedir("/sys/bus/pci/devices")
> 
> Now I admit that the code getting the info from /proc was more compact,
> but it misses the domain and the class, and adding them would make the
> code MUCH more complex, so I'm not gonna do it.
> 
> I attached the real code in case someone wants to take a look and
> comment. I'll probably apply it soon if no objections arise.

I just applied a cleaned-up version of this patch to SVN.

-- 
Jean Delvare