Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle /sys/devices/virtual/{nvme-fabrics,nvme-subsystem} devices #139

Merged
merged 10 commits into from
Oct 18, 2019

Conversation

vathpela
Copy link
Contributor

@vathpela vathpela commented Oct 2, 2019

This fixes some minor bugs, adds some debug logging to the parsers, and adds support for devices that show up in /sys/device/virtual/nvme-subsystem/ and /sys/device/virtual/nvme-fabrics/ .

Ritchie wrote in '84:

 If there are fewer initializers in the list than there are members of
 the aggregate, then the aggregate is padded with 0's.

c99 §6.7.8 and c11 §6.7.9 each say:

 10 If an object that has automatic storage duration is not initialized
    explicitly, its value is indeterminate. If an object that has static
    storage duration is not initialized explicitly, then:
    — if it has pointer type, it is initialized to a null pointer;
    — if it has arithmetic type, it is initialized to (positive or
      unsigned) zero;
    — if it is an aggregate, every member is initialized (recursively)
      according to these rules;
    — if it is a union, the first named member is initialized
      (recursively) according to these rules.
...
 21 If there are fewer initializers in a brace-enclosed list than there
    are elements or members of an aggregate, or fewer characters in a
    string literal used to initialize an array of known size than there
    are elements in the array, the remainder of the aggregate shall be
    initialized implicitly the same as objects that have static storage
    duration.

This warning is thoroughly pointless.

Signed-off-by: Peter Jones <pjones@redhat.com>
If we know our log will only be seen by strace, the newlines don't add
anything to the strings but clutter.

Signed-off-by: Peter Jones <pjones@redhat.com>
This adds highlights under the things we've found when searching, like:

linux-pci.c:66 parse_pci(): searching for 0000:00:00.0/
linux-pci.c:69 parse_pci(): current:'0000:00:1d.4/0000:6e:00.0/nvme/nvme0/nvme0n1' rc:4 pos0:0 pos1:13
linux-pci.c:70 parse_pci():          ^^^^^^^^^^^^^

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
Apparently I wrote some of these one way and some the other, and the one
special case where everything was "current+sz" instead of some form of
"current += pos; sz += pos; ...; return sz;" or the subtraction version.

Make them all the same, where possible.

Signed-off-by: Peter Jones <pjones@redhat.com>
This changes debug prints in a couple of ways:
- always calls the path we're parsing "current" in the output
- always use ' not " for quoting in the debug output, so tools that
  escape strings won't change the lenghts
- everything that parses "current" has a debug print after each parse
  attempt and before returning.

Signed-off-by: Peter Jones <pjones@redhat.com>
Today's realization is that the thing encoded into the structure of
sysfs is, in the best case, the dependency graph of the makefile targets
to build a device driver.

In the case of nvme-fabric, or really wherever the kernel has
class_create() and device_create() in the same function, there's an
extra level of indirection.

Anyway, in this patch we stop pretending sysfs isn't completely absurd,
and just try adding "/device" in the middle of the driver symlink path,
until we actually either get ENOENT on the device symlink or find a
device symlink that actually has a driver symlink under it.

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
@vathpela vathpela merged commit ca85d51 into rhboot:master Oct 18, 2019
@vathpela vathpela deleted the nvme-subsystem branch July 8, 2020 19:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant