I said:
In libpci_access-016/src/hurd_pci.c, there is enum_devices that I think may be a recursive scan of PCI devices
Looks like I was a bit wrong here.
Because the comment says it scan the filesystem... which I now presume is:
/servers/bus/pci
[domain:]bus:device.function
domain: /servers/bus/pci/0000 is not shown by lspci.
Like in qemu I have:
root@debian:/servers/bus/pci/0000/00/00/0# lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 VGA compatible controller: Device 1234:1111 (rev 02)
The first value: 00 is the bus, and here there is just one.
There is 3 devices on bus 00:
-00 is 440FX
-01 is 82371 chip
-02 is VGA card
The 01 device on bus 00, has 3 functions:
-0 ISA bridge
-1 IDE interface
-3 Bridge
Like the bridge (bus:00, devices 01, function 3): would be on:
root@debian:/servers/bus/pci/0000/00/01/3# ls -lh
total 8.0K
-rw-rw---- 2 root root 256 Oct 26 12:16 config
root@debian:/servers/bus/pci/0000/00/01/3#
Seems all functions of devices have at least ths 256 bytes config.
But the can contains regions files, rom, each can be 16Mib long, so it can become a bit big.
My initial idea was to create a tar.gz file of the /servers/bus/pci/ directory as a kind of scanned "real" pci scan.
This kind of confirms the problem cannot be in this detection itself, because there cannot be four: /servers/bus/pci/0000/00/01/03 files.
I now believe the pci scan I was searching for is more in the:
libpci/libpciaccess-0.16/src/x86_pci.c:
/* Recursively scan bus number `bus' */
static error_t
pci_system_x86_scan_bus (uint8_t bus)
Which I am kind beginning to look at.