What?

The following fields could be represented as integers:

class_id: String -> class_id: usize
vendor_id: String -> vendor_id: usize
device_id: String -> device_id: usize
// Spoilers ahead!
subsystem_vendor_id: String -> subsystem_vendor_id: usize
subsystem_device_id: String -> subsystem_device_id: usize

Why?

Using String for fields that may as well be integers, is very expensive.

In version 5.0, the Linux implementation of Fetch was removed so it could be reworked. It will now be reimplemented but with performance in mind.

What must be done different?

• Fetch::fetch_by_class() in previous versions would create a PCIDevice out of every PCI device it could find, then and only then, does it remove the irrelevant PCI devices, and this costs time and is so inefficient it literally blows my mind why I decided to implement it the way I did.

Nice-To-Haves

• A new method, something along the lines of Fetch::fetch_by_subclass(name) where name is of type String. This method should return only the PCI devices whose subclass (click any click to see subclasses) is equal to what was provided to the method. It is unmaintainable for me to provide an enum with ready-to-use subclasses, because there's well over 50 of these, and they're always changing.

Addressing slowness

aparato runs really, really slooow when fetching PCI devices in bulk, through fetch(), fetch_by_class() or fetch_gpus() If you're instantiating one PCI device, the performance is acceptable (around 3-5ms), but when you're fetching multiple devices, that's when you notice how slow it can get (around 80-90ms).

Description

fetch_by_class() appears to be broken (returns nothing), passing any variant of DeviceClass to the function results in the same behavior.

To reproduce:

let thing: Vec<PCIDevice> = PCIDevice::fetch_by_class(DeviceClass::NetworkController);
println!("{:?}", thing);

37672bea637fea077b568452ee4373b22ccba8e4 fixes this.

What's different?

• The linux directory now contains only one module.
• There's unit tests now!
• There is no longer a need to run init() after instantiating a PCIDevice
• A PCIDevice that was fetched through instantiating the PCIDevice through PCIDevice::new() now fetches and sets the following fields: device_name, vendor_name
• Fetchers such as fetch() and fetch_by_class() are now part of a new Fetch trait, making the structure of the library a lot nicer to work, and it makes more sense this way.

Bonus

• DeviceClass offers more informative documentation.
• PATH_TO_PCI_IDS was introduced with the purpose of holding the path to the pci.ids file.

Todo

• [ ] ~~Address a bug which results in device_name() and class_name() returning absolutely nothing.~~

Nope, no bugs, I was misusing the library.

Hi,

Thanks for for your crate. I've been testing it with mixed results as in two systems the hw listed seems ok but the other one the results are wrong. I looked at you code and found the error on the set_*_name() functions for device and subsystem.

The parser generate not valid results due to the following bugs in your code when parsing pci id file:

• Device name: Vendor is not considered (first step in decoding should be to locate the vendor section in the file) & the parsing do not discard '\t\t' lines that describe subystems.
• Subsystem name: Vendor ins not considered as in the device name.

I think these bugs are easy to fix. I can do a PR but I don't know if you are working on that as I see that you have a open PR to address accuracy.

When building aparato on ppc64le and s390x the tests fail.

ppc64le:

    Running `/builddir/build/BUILD/aparato-6.0.0/target/release/deps/aparato-5a9ba48135f0c5e6`
running 10 tests
test linux::tests::test_address ... ok
test linux::tests::test_class_id ... FAILED
test linux::tests::test_device_id ... FAILED
test linux::tests::test_path ... ok
test linux::tests::test_class_name ... FAILED
test linux::tests::test_revision ... FAILED
test linux::tests::test_subsystem_device_id ... FAILED
test linux::tests::test_subsystem_vendor_id ... FAILED
test linux::tests::test_vendor_id ... FAILED
test linux::tests::test_numa_node ... ok
failures:
---- linux::tests::test_class_id stdout ----
thread 'linux::tests::test_class_id' panicked at 'assertion failed: `(left != right)`
  left: `[]`,
 right: `[]`', src/linux/mod.rs:556:9
---- linux::tests::test_device_id stdout ----
thread 'linux::tests::test_device_id' panicked at 'assertion failed: `(left != right)`
  left: `[]`,
 right: `[]`', src/linux/mod.rs:568:9
---- linux::tests::test_class_name stdout ----
thread 'linux::tests::test_class_name' panicked at 'assertion failed: `(left != right)`
  left: `""`,
 right: `""`', src/linux/mod.rs:598:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
---- linux::tests::test_revision stdout ----
thread 'linux::tests::test_revision' panicked at 'assertion failed: `(left != right)`
  left: `[]`,
 right: `[]`', src/linux/mod.rs:580:9
---- linux::tests::test_subsystem_device_id stdout ----
thread 'linux::tests::test_subsystem_device_id' panicked at 'assertion failed: `(left != right)`
  left: `[]`,
 right: `[]`', src/linux/mod.rs:592:9
---- linux::tests::test_subsystem_vendor_id stdout ----
thread 'linux::tests::test_subsystem_vendor_id' panicked at 'assertion failed: `(left != right)`
  left: `[]`,
 right: `[]`', src/linux/mod.rs:586:9
---- linux::tests::test_vendor_id stdout ----
thread 'linux::tests::test_vendor_id' panicked at 'assertion failed: `(left != right)`
  left: `[]`,
 right: `[]`', src/linux/mod.rs:562:9
failures:
    linux::tests::test_class_id
    linux::tests::test_class_name
    linux::tests::test_device_id
    linux::tests::test_revision
    linux::tests::test_subsystem_device_id
    linux::tests::test_subsystem_vendor_id
    linux::tests::test_vendor_id
test result: FAILED. 3 passed; 7 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

s390x:

     Running `/builddir/build/BUILD/aparato-6.0.0/target/release/deps/aparato-dbbd6af19f4502c3`
running 10 tests
test linux::tests::test_address ... ok
test linux::tests::test_class_name ... FAILED
test linux::tests::test_device_id ... FAILED
test linux::tests::test_numa_node ... ok
test linux::tests::test_path ... ok
test linux::tests::test_subsystem_device_id ... FAILED
test linux::tests::test_revision ... FAILED
test linux::tests::test_subsystem_vendor_id ... FAILED
test linux::tests::test_vendor_id ... FAILED
test linux::tests::test_class_id ... FAILED
failures:
---- linux::tests::test_class_name stdout ----
thread 'linux::tests::test_class_name' panicked at 'assertion failed: `(left != right)`
  left: `""`,
 right: `""`', src/linux/mod.rs:598:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
---- linux::tests::test_device_id stdout ----
thread 'linux::tests::test_device_id' panicked at 'assertion failed: `(left != right)`
  left: `[]`,
 right: `[]`', src/linux/mod.rs:568:9
---- linux::tests::test_subsystem_device_id stdout ----
thread 'linux::tests::test_subsystem_device_id' panicked at 'assertion failed: `(left != right)`
  left: `[]`,
 right: `[]`', src/linux/mod.rs:592:9
---- linux::tests::test_revision stdout ----
thread 'linux::tests::test_revision' panicked at 'assertion failed: `(left != right)`
  left: `[]`,
 right: `[]`', src/linux/mod.rs:580:9
---- linux::tests::test_subsystem_vendor_id stdout ----
thread 'linux::tests::test_subsystem_vendor_id' panicked at 'assertion failed: `(left != right)`
  left: `[]`,
 right: `[]`', src/linux/mod.rs:586:9
---- linux::tests::test_vendor_id stdout ----
thread 'linux::tests::test_vendor_id' panicked at 'assertion failed: `(left != right)`
  left: `[]`,
 right: `[]`', src/linux/mod.rs:562:9
---- linux::tests::test_class_id stdout ----
thread 'linux::tests::test_class_id' panicked at 'assertion failed: `(left != right)`
  left: `[]`,
 right: `[]`', src/linux/mod.rs:556:9
failures:
    linux::tests::test_class_id
    linux::tests::test_class_name
    linux::tests::test_device_id
    linux::tests::test_revision
    linux::tests::test_subsystem_device_id
    linux::tests::test_subsystem_vendor_id
    linux::tests::test_vendor_id
test result: FAILED. 3 passed; 7 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

You can find the full logs at https://koji.fedoraproject.org/koji/taskinfo?taskID=72224758 and https://koji.fedoraproject.org/koji/taskinfo?taskID=72224759 (look at build.log).