Francesco Romani

@taigrr thanks! I'll review the issue from the ground up trying to cover all the angles and will share my thoughts (here or in a GH issue). I want to...

from my POV this change addresses a real issue and I can't think of a better way to solve this problem. Besides some bookkeeping (resolve conflict, remove merge commit) ,...

thanks @taigrr . I want to check we're addressing @Itxaka 's concern raised in https://github.com/jaypipes/ghw/pull/308#issuecomment-1073722864 . I'll work a bit more on some test cases that should cover this flow,...

thanks @taigrr for your patience and thanks to @Itxaka for the feedback. I've been thinking on/off about the best way to meet all the requirements here and I can't find...

Example output, PF device: `lssriov` is the same code shown in the example added to the README (see) ``` ./lssriov 0000:05:00.0 | jq { "driver": "igb", "interfaces": [ "enp5s0f0" ],...

Example output, VF device: `lssriov` is the same code shown in the example added to the README (see) ``` /lssriov 0000:05:10.0 | jq { "driver": "igbvf", "interfaces": [ "enp5s0f0v0" ],...

We are converging about which information we should expose about SRIOV devices. The current set of attributes represents what other established components, for example the [k8s SRIOV operator exposes](https://github.com/openshift/sriov-network-operator/blob/master/api/v1/sriovnetworknodestate_types.go) ....

> We are converging about which information we should expose about SRIOV devices. The current set of attributes represents what other established components, for example the [k8s SRIOV operator exposes](https://github.com/openshift/sriov-network-operator/blob/master/api/v1/sriovnetworknodestate_types.go)...

ok, test failure is unexpected. I'll have a look ASAP.

> ok, test failure is unexpected. I'll have a look ASAP. weird, can't reproduce inside a xenial container: ``` FROM ubuntu:xenial RUN apt update RUN apt install -y curl git...