On Wed, Nov 26, 2008 at 11:24 PM, Kay Sievers <kay.sievers@xxxxxxxx> wrote: > On Thu, Nov 27, 2008 at 04:25, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: >> On Wed, Nov 26, 2008 at 5:13 PM, Kay Sievers <kay.sievers@xxxxxxxx> wrote: >>> On Thu, Nov 27, 2008 at 00:45, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: >>>> This implementation crawls through sysfs to put this information >>>> together, I believe it is crawling in a future proof fashion, but here >>>> are my assumptions: >>>> 1/ /sys/bus/pci/drivers/ahci/<x>/device will identify a pci ahci device >>> >>> Why "device"? You just check for the "device" attribute file of the PCI device? >>> >> >> $ ls /sys/bus/pci/drivers/ahci/ >> 0000:00:1f.2/ module/ uevent >> bind new_id unbind >> >> I look for the 'device' file to disambiguate '0000:00:1f.2' from >> 'module' or some other object that appears in the future. The other >> attributes are discarded because they are not directories. > > But only devices of the bus "pci" have this attribute. The code looks > like it it should be able to handle some other buses to, at least the > bus values is passed around, but the pci-device attribute "device" is > hard coded. That's why I asked. > It's fine if you want to do it that way. If you just look for a > "struct device" of that <bus>, resolving "subsystem" and checking if > the tail of the string matches "/<bus>" should be fine. gah, I was confusing the 'device' I find here "/sys/block/sda/device" with the pci device id. Yes, checking on 'subsystem' seems to be exactly what I want. Thanks, Dan -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
