[pciutils,0/4] Support for PCI_FILL_DRIVER

Message

Pali Rohár Jan. 21, 2022, 2:03 p.m. UTC

Both procfs and sysfs provides information about used PCI driver.
Add support for a new libpci string property PCI_FILL_DRIVER, fill it in
both procfs ans sysfs provides and use it in lspci instead of lspci own
sysfs code for retrieving driver.

This patch series is based on top of another patch series:
https://lore.kernel.org/linux-pci/[e-mail]/t/

Pali Rohár (4):
  libpci: Define new string property PCI_FILL_DRIVER
  libpci: proc: Implement support for PCI_FILL_DRIVER
  libpci: sysfs: Implement support for PCI_FILL_DRIVER
  lspci: Replace find_driver() via libpci PCI_FILL_DRIVER

 lib/pci.h   |  1 +
 lib/proc.c  | 22 +++++++++++++++++++--
 lib/sysfs.c | 13 +++++++++++++
 ls-kernel.c | 56 +++++++++++++++--------------------------------------
 4 files changed, 50 insertions(+), 42 deletions(-)

Comments

Martin Mareš Jan. 21, 2022, 2:31 p.m. UTC | #1

Hello!

> Both procfs and sysfs provides information about used PCI driver.
> Add support for a new libpci string property PCI_FILL_DRIVER, fill it in
> both procfs ans sysfs provides and use it in lspci instead of lspci own
> sysfs code for retrieving driver.

Is there any meaningful difference in the reported data?

				Martin

Pali Rohár Jan. 21, 2022, 2:40 p.m. UTC | #2

On Friday 21 January 2022 15:31:42 Martin Mareš wrote:
> Hello!
> 
> > Both procfs and sysfs provides information about used PCI driver.
> > Add support for a new libpci string property PCI_FILL_DRIVER, fill it in
> > both procfs ans sysfs provides and use it in lspci instead of lspci own
> > sysfs code for retrieving driver.
> 
> Is there any meaningful difference in the reported data?

Reported data are exactly same. Just with this change lspci can report
driver also for non-sysfs backend (e.g. procfs backend or new WIP win32
backend).

Basically sysfs logic from lspci executable was moved into the libpci
library and therefore now it is available also for other applications.


So difference for -A linux-proc is following:

Without this patch series:
./lspci -A linux-proc -s 00:02.0 -v
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller])
        Subsystem: Dell 4th Gen Core Processor Integrated Graphics Controller
        Flags: bus master, fast devsel, latency 0, IRQ 33
        Memory at f5800000 (64-bit, non-prefetchable) [size=4M]
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at f000 [size=64]
        Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
        Capabilities: <access denied>

And with this patch series:
./lspci -A linux-proc -s 00:02.0 -v
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller])
        Subsystem: Dell 4th Gen Core Processor Integrated Graphics Controller
        Flags: bus master, fast devsel, latency 0, IRQ 33
        Memory at f5800000 (64-bit, non-prefetchable) [size=4M]
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at f000 [size=64]
        Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel driver in use: i915

Martin Mareš Jan. 21, 2022, 2:46 p.m. UTC | #3

Hello!

> Reported data are exactly same. Just with this change lspci can report
> driver also for non-sysfs backend (e.g. procfs backend or new WIP win32
> backend).
> 
> Basically sysfs logic from lspci executable was moved into the libpci
> library and therefore now it is available also for other applications.

I am not convinced that it is right to make something with so vague
semantics a part of libpci API.

The procfs back-end is a pretty weak motivation, because it's long obsolete
and basically I haven't dropped it yet only because it takes more effort
than letting it stay :-)

Now, the win32 back-end could be intersting, but let's make it mergeable
in its basic form first.

				Martin