Thread: Help with pciutils-dev

I am trying to familiarize myself with pciutils-dev C library, and I came across this example file.

For simplicity, let me write (a mildly changed version of) example.c here:

Code:

    int main(int argc, char* argv[]) {
    
        struct pci_access*    pacc;
        struct pci_dev*        dev;
    
        pacc = pci_alloc();
        pci_init(pacc);
        pci_scan_bus(pacc);
    
        for (dev = pacc->devices; dev; dev = dev->next) {
            pci_fill_info(dev, PCI_FILL_IDENT | PCI_FILL_BASES | PCI_FILL_CLASS);
            printf("%02x:%02x.%d vendor=%04x device=%04x class=%04x irq=%d base0=%lx\n",
                dev->bus, dev->dev, dev->func, dev->vendor_id, dev->device_id,
                dev->device_class, dev->irq, (long) dev->base_addr[0]);
        }
    
        pci_cleanup(pacc);
        return 0;
    }

I omitted things I'm not interested in right now.
So, I'm am trying to find out what does pci_fill_info() do.
Now, you're right, its name and arguments kinda give it away, and plus this helps revealing more (from here):

Code:

struct pci_dev {
    struct pci_dev *next;         /* Next device in the chain */
    u16 domain;               /* PCI domain (host bridge) */
    u8 bus, dev, func;            /* Bus inside domain, device and function */

    /* These fields are set by pci_fill_info() */
    int known_fields;         /* Set of info fields already known */
    u16 vendor_id, device_id;     /* Identity of the device */
    u16 device_class;         /* PCI device class */
    int irq;              /* IRQ number */
    pciaddr_t base_addr[6];       /* Base addresses including flags in lower bits */
    pciaddr_t size[6];            /* Region sizes */
    pciaddr_t rom_base_addr;      /* Expansion ROM base address */
    pciaddr_t rom_size;           /* Expansion ROM size */
    struct pci_cap *first_cap;        /* List of capabilities */
    char *phy_slot;           /* Physical slot */
    char *module_alias;           /* Linux kernel module alias */
    char *label;              /* Device name as exported by BIOS */
    int numa_node;            /* NUMA node */

    /* Fields used internally: */
    struct pci_access *access;
    struct pci_methods *methods;
    u8 *cache;                /* Cached config registers */
    int cache_len;
    int hdrtype;              /* Cached low 7 bits of header type, -1 if unknown */
    void *aux;                /* Auxillary data */
};

Nonetheless, I wanted to be sure that it does what I think it does.
So I looked everywhere for its definition and couldn't find it!
Please, if anyone knows where I can find its implementation. that would be great!

Another weird thing that happens; is that when I tried to confirm the function's mode of operation, something unexpected happened.

Consider this:

Code:

int main(int argc, char* argv[]) {

    struct pci_access*    pacc;
    struct pci_dev*        dev;

    pacc = pci_alloc();
    pci_init(pacc);
    pci_scan_bus(pacc);

    for (dev = pacc->devices; dev; dev = dev->next) {
        struct pci_dev* temp = dev->next;
        memset(dev, 0, sizeof(dev));
        dev->next = temp;
        pci_fill_info(dev, PCI_FILL_IDENT);
        printf("%02x:%02x.%d vendor=%04x device=%04x class=%04x irq=%d base0=%lx\n",
            dev->bus, dev->dev, dev->func, dev->vendor_id, dev->device_id,
            dev->device_class, dev->irq, (long) dev->base_addr[0]);
    }

    pci_cleanup(pacc);
    return 0;
}

Notice that the only flag I give to pci_fill_info() is PCI_FILL_IDENT, but the above still prints valid values for all the fields!
It is as if pci_fill_info() completely ignores the flags, and just populate the entire struct!

Is anyone familiar with this function and can shed some light?

Thanks.

The line

Originally Posted by Absurd

Code:

        memset(dev, 0, sizeof(dev));

clears the first (size of a pointer) bytes of the structure pointed to by dev; in Linux, that is just the 'next' member.

Your code basically just ends up saving the value of the next member in the dev structure, clearing it, and copying it back. Not what you indented, I'd wager.

Modifying these structures is not a sane approach. Your program should not do that.

However, I can see why doing so is interesting for learning purposes. With the caveat that this is not even supposed to work -- because the structure is supposed to be informational, not messed with willy-nilly --, here is the approach I recommend. In the loop body:

Code:

        struct pci_dev  custom; /* Not a pointer! */

        memset(&custom, 0, sizeof custom);

        /* Copy the PCI device identifiers. */
        custom.domain = dev->domain;
        custom.bus = dev->bus;
        custom.dev = dev->dev;
        custom.func = dev->func;

        /* Copy the internal fields the library expects to be there */
        custom.access = dev->access;
        custom.methods = dev->methods;
        custom.cache = dev->cache;
        custom.cache_len = dev->cache_len;
        custom.hdrtype = dev->hdrtype;
        custom.aux = dev->aux;

        /* Fill in the device information */
        pci_fill_info(&custom, ...);

That will leak some memory, as the capabilities list is lost as custom goes out of scope, but it's all recovered by the kernel when the process exits, so it's okay for exploration.

The source for pci_fill_info() is in lib/access.c in the source tree. It is actually a versioned alias; at the HEAD the current function is actually pci_fill_info_v34(). You can find the name by using readelf -s or objdump -t on your pciutils library file (to list all symbol names). The actual function is the highest versioned one.

Before you get excited, that function is trivial. Because the library supports all kinds of systems, it stores the pointers to the correct access functions (like fill_info) in a structure hanging off the methods member in the dev structure. That function -- and there are several implementations; which one gets called depends on the system and bus -- is responsible for filling in the fields. Look at the source tree, at the various type_fill_info() functions.

For Linux, I guess the lib/sysfs.c:sysfs_get_info() and lib/generic.c:pci_generic_fill_info() are most interesting.

Originally Posted by Salem

So long as the implementation conforms to it's specification, I don't think there is much to worry about.

That is actually what I was looking for. Its specification...

Originally Posted by Nominal Animal

The line

clears the first (size of a pointer) bytes of the structure pointed to by dev; in Linux, that is just the 'next' member.

Your code basically just ends up saving the value of the next member in the dev structure, clearing it, and copying it back. Not what you indented, I'd wager.

You're right. That's not what I was aiming for... This should have been sizeof(struct pci_dev)...

Originally Posted by Nominal Animal

Modifying these structures is not a sane approach. Your program should not do that.

However, I can see why doing so is interesting for learning purposes. With the caveat that this is not even supposed to work -- because the structure is supposed to be informational, not messed with willy-nilly --, here is the approach I recommend. In the loop body:

Code:

        struct pci_dev  custom; /* Not a pointer! */

        memset(&custom, 0, sizeof custom);

        /* Copy the PCI device identifiers. */
        custom.domain = dev->domain;
        custom.bus = dev->bus;
        custom.dev = dev->dev;
        custom.func = dev->func;

        /* Copy the internal fields the library expects to be there */
        custom.access = dev->access;
        custom.methods = dev->methods;
        custom.cache = dev->cache;
        custom.cache_len = dev->cache_len;
        custom.hdrtype = dev->hdrtype;
        custom.aux = dev->aux;

        /* Fill in the device information */
        pci_fill_info(&custom, ...);

That will leak some memory, as the capabilities list is lost as custom goes out of scope, but it's all recovered by the kernel when the process exits, so it's okay for exploration.

The source for pci_fill_info() is in lib/access.c in the source tree. It is actually a versioned alias; at the HEAD the current function is actually pci_fill_info_v34(). You can find the name by using readelf -s or objdump -t on your pciutils library file (to list all symbol names). The actual function is the highest versioned one.

Before you get excited, that function is trivial. Because the library supports all kinds of systems, it stores the pointers to the correct access functions (like fill_info) in a structure hanging off the methods member in the dev structure. That function -- and there are several implementations; which one gets called depends on the system and bus -- is responsible for filling in the fields. Look at the source tree, at the various type_fill_info() functions.

For Linux, I guess the lib/sysfs.c:sysfs_get_info() and lib/generic.cci_generic_fill_info() are most interesting.

Yes. The only reason for doing so was to see how it works.

Thanks!

OK, I cleared the fields one at a time:

Code:

int main(int argc, char* argv[]) {

    struct pci_access*    pacc;
    struct pci_dev*        dev;

    pacc = pci_alloc();
    pci_init(pacc);
    pci_scan_bus(pacc);

    for (dev = pacc->devices; dev; dev = dev->next) {
        dev->bus = 0;
        dev->dev = 0;
        dev->func = 0;
        dev->vendor_id = 0;
        dev->device_id = 0;
        dev->device_class = 0;
        dev->irq = 0;
        dev->base_addr[0] = 0;
        
        pci_fill_info(dev, PCI_FILL_IDENT | PCI_FILL_BASES | PCI_FILL_CLASS);
        printf("%02x:%02x.%d vendor=%04x device=%04x class=%04x irq=%d base0=%lx\n",
            dev->bus, dev->dev, dev->func, dev->vendor_id, dev->device_id,
            dev->device_class, dev->irq, (long) dev->base_addr[0]);
    }

    pci_cleanup(pacc);
    return 0;
}

But this prints nothing but zeros everywhere...

00:00.0 vendor=0000 device=0000 class=0000 irq=0 base0=0
00:00.0 vendor=0000 device=0000 class=0000 irq=0 base0=0
00:00.0 vendor=0000 device=0000 class=0000 irq=0 base0=0
00:00.0 vendor=0000 device=0000 class=0000 irq=0 base0=0
00:00.0 vendor=0000 device=0000 class=0000 irq=0 base0=0
00:00.0 vendor=0000 device=0000 class=0000 irq=0 base0=0
00:00.0 vendor=0000 device=0000 class=0000 irq=0 base0=0
00:00.0 vendor=0000 device=0000 class=0000 irq=0 base0=0
00:00.0 vendor=0000 device=0000 class=0000 irq=0 base0=0
00:00.0 vendor=0000 device=0000 class=0000 irq=0 base0=0
00:00.0 vendor=0000 device=0000 class=0000 irq=0 base0=0
00:00.0 vendor=0000 device=0000 class=0000 irq=0 base0=0
00:00.0 vendor=0000 device=0000 class=0000 irq=0 base0=0

What's wrong with it? Why is pci_fill_info() suddenly does not work when you clear these fields before calling it?

Originally Posted by Absurd

OK, I cleared the fields one at a time:

You might have missed my point: my code clears a device structure, then copies to it the bare minimum fields needed for the library to work at all.

You must not zero:

• domain, because it identifies the domain (PCI bridge) used for this particular device
• bus, dev, or func, because they identify the PCI device in this domain
• access, methods, cache, cache_len, hdrtype, or aux, because they are internal fields used by the library
• next, because it is used to iterate through the list

If you clear any of those, you cannot expect the library to work right. If you clear any or all of the four fields listed first above, the library no longer knows which device the structure is supposed to refer to. If you clear any of the internal fields, the library will (likely) malfunction. If you clear the next field, you won't see any but the very first device in the chain.

Ohh... OK. Now it all makes sense.
Thanks again!