nvme: make "nvme list" do not report an error when the modules are not loaded

[Cav4ever]

On nvme-cli 1.x, nvme list is no-ops when the nvme_core module isn't loaded:

# nvme list
Node                  SN                   Model                                    Namespace Usage                      Format           FW Rev
--------------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------

But on nvme-cli 2.x, it fails when trying to open the nonexistent /sys/class/nvme. It would be nice for the command to be no-ops again.

 # nvme list
Failed to scan topology: No such file or directory

commit 283585a fixes the issue, but commit f17afe1 reverts the change.

[Cav4ever]

@igaw Hi Daniel，please help me review this patch.

[igaw]

The commit message should contain the reason why this change is necessary. And given the amount of time this exact code has been touched by either someone complaining it should print a warning or not I have the suspicion this is going to cause another discussion.

[Cav4ever]

@igaw

The commit message should contain the reason why this change is necessary.

Thank you for your review. I have revised the commit message; kindly take another look.

To ensure consistency, it would be better if the behavior of "nvme list" in version 2.x matched that of version 1.x when the NVMe modules are not loaded.

[igaw]

I have to dig into it again. But one thing is, that I am extremely hesitant to change the behavior 3 years after we have released 2.x.

[igaw]

I'll look into it after the v2.15 release. Just not enough time to dive into this topic right now.

[tbzatek]

<OT> Yeah, it's the kind of annoyance when user needs to modprobe manually. Similar situation with nvme connect missing the nvme-fabrics module or with nvmetcli complaining about a missing nvmet module. In all these cases user gets rather cryptic message, not immediately pointing to a module to be loaded.

[igaw]

Please discuss this out with @martin-gpy who added this feature f17afe1 ("fabrics: print an error for ENOENT too")

Obviously, you can't have both.

[igaw]

One idea I had was to make the default failing silent, that is if you just do a nvme list. And when the user provides nvme list --verbose it shows the error/warning/help message. Would that work?

[martin-gpy]

One idea I had was to make the default failing silent, that is if you just do a nvme list. And when the user provides nvme list --verbose it shows the error/warning/help message. Would that work?

That's still not ideal. A default silent failing only compounds the confusion as to why it has failed, and it is not intuitive to run it with the verbose option to see the actual failure message.

[martin-gpy]

I don't understand why ENOENT alone has to be treated as a no-ops unlike other errors. A no-ops serves no purpose but only to confuse further as to why it failed. Agreed we are using a generic error message here, but that applies to all errors and not just ENOENT.

Can someone explain why ENOENT alone has to be treated separately (as a no-ops) unlike other errors here? What is so special about ENOENT?