Inspect Installed Buses Safely through /proc/bus

You will identify the bus interfaces exposed by the running Linux kernel, inspect the PCI device listing, and decide when to use lspci or setpci instead of reading procfs files directly. The workflow is read-only. Allow about ten minutes, and expect the exact directories and device list to vary between machines.

This guide uses the installed proc_bus(5) page from Linux man-pages 6.7-2, on a Linux 6.8.0-139-generic kernel. The page describes an interface supplied by the kernel, so its contents are host-specific. You need a shell. The normal examples do not need elevated privileges.

1. List the bus interfaces that exist

Start at the directory named by the manual page:

$ find /proc/bus -maxdepth 2 -print 2>/dev/null | sort
/proc/bus
/proc/bus/input
/proc/bus/input/devices
/proc/bus/input/handlers
/proc/bus/pci
/proc/bus/pci/00
/proc/bus/pci/devices

Your output can be shorter or longer. The important point is that /proc/bus/ contains subdirectories for buses installed and exposed by this kernel. Do not treat the absence of a particular directory as proof that the physical bus does not exist: kernel configuration, hardware, virtualisation and procfs visibility all affect what is exposed.

Checkpoint: confirm that the directory is readable without changing anything:

$ test -d /proc/bus && echo '/proc/bus is present'
/proc/bus is present

2. Inspect the PCI device file

The manual identifies /proc/bus/pci/devices as the PCI device information file. Read a few lines rather than dumping an unknown-size file into your terminal:

$ head -n 5 /proc/bus/pci/devices
0000	8086591f	0	               0	               0	               0	               0
0010	80865912	b	        ee000004	               0	        d000000c	               0
00a0	8086a12f	7c	        ef020004	               0	               0	               0

Each line is a kernel-generated record, not a portable report format for your own parser. The first fields identify a PCI location and device identifier; the remaining fields contain resource information. The precise spacing and number of fields are kernel-version details. If you need a stable, human-facing inventory, use the PCI utilities in the next step.

A procfs file can report zero bytes with stat even though a read returns records, because procfs generates content when it is read:

$ stat -c '%F %s bytes %n' /proc/bus/pci/devices
regular empty file 0 bytes /proc/bus/pci/devices

That is not the same as an ordinary empty file. Do not copy it, truncate it or try to edit it. The file is an interface to live kernel state.

3. Use lspci for a readable inventory

The proc_bus(5) page says that the PCI device file may be accessed through lspci(8). On this machine, lspci is version 3.10.0:

$ command -v lspci
/usr/bin/lspci
$ lspci
00:00.0 Host bridge: ...
00:02.0 VGA compatible controller: ...

The device names and addresses above are examples of shape, not a promise about your hardware. If the output is too detailed, run the plain command first and add one display option at a time. For a script or report that needs machine-readable records, check the installed lspci documentation before choosing a format; do not parse the private spacing of /proc/bus/pci/devices by accident.

To relate a device to its kernel driver, use the installed utility's driver display option:

$ lspci -k
00:00.0 Host bridge: ...
	Kernel driver in use: ...

The ellipses mean that your host will provide the real device and driver names. A missing driver line is information to investigate, not a reason to write to procfs.

4. Treat setpci as a hardware-change boundary

The same manual page names setpci(8) as another way to access PCI device information. It is more sensitive than an inventory command because PCI configuration-space operations can affect hardware behaviour. Confirm the utility and read its help before using it:

$ command -v setpci
/usr/bin/setpci
$ setpci --help 2>&1 | head -n 12
Usage: setpci [options] <config operations>

Where options are:
...

Do not paste a write operation from an unverified example. A command that changes PCI configuration space can disrupt a device, hang a bus or leave hardware in a state that is not restored by closing the shell. If you only need to identify a device, stop at lspci. If you must change a register, use the hardware vendor's documentation, arrange console access and record a recovery plan first. Elevated privileges may be required, but sudo does not make an unsafe register write safe.

5. Check for PCMCIA without assuming it is supported

The manual describes /proc/bus/pccard/ as the PCMCIA directory when the kernel was compiled with CONFIG_PCMCIA. Test for it explicitly:

$ if test -d /proc/bus/pccard; then
    printf '%s\n' 'PCMCIA procfs interface is present'
    find /proc/bus/pccard -maxdepth 2 -print
else
    printf '%s\n' 'No /proc/bus/pccard directory is exposed'
fi
No /proc/bus/pccard directory is exposed

On a modern machine, a missing directory may simply mean that PCMCIA support is not built or no such interface is exposed. Do not create the directory yourself: procfs entries are provided by the kernel, and a manually created directory would not provide bus information.

6. Diagnose the common wrong assumptions

If /proc/bus is missing, first check whether procfs is mounted at all:

$ findmnt /proc
TARGET SOURCE FSTYPE OPTIONS
/proc  proc   proc   rw,nosuid,nodev,noexec,relatime

If this produces no row, the issue is broader than PCI. Ask your platform administrator how procfs is mounted rather than creating arbitrary directories under /proc. Mounting filesystems is an administrative operation and can affect services, so it is deliberately outside this read-only guide.

If /proc/bus/pci exists but the device list differs from another machine, compare the kernel, virtual machine configuration and hardware. The file describes the running host, not an inventory database. If a command cannot read a procfs entry, record the exact error and inspect permissions and security policy before reaching for root. Running as root can bypass an access problem while hiding the reason ordinary monitoring failed.