On Thu, Nov 16, 2023 at 03:03:20AM +0000, Shinichiro Kawasaki wrote: > > The idea looked good and I checked /dev/nvme-fabrics content on kernel v6.7- > > rc1. But unfortunately, I found that /dev/nvme-fabrics content is same > > regardless of the kernel config NVME_HOST_AUTH. I checked opt_tokens in > > drivers/nvme/host/fabrics.c, and saw that "dhchap_ctrl_secret=%s" is not > > surrounded with #ifdef CONFIG_NVME_HOST_AUTH. Should we add the > > #ifdef? Yes. The whole point of adding the features to /dev/nvme-fabrics is that we can figure out easily what is supported. If dhchap_ctrl_secret is not working due missing CONFIG_NVME_HOST_AUTH, then it should not be in the list. > > I tried to find out other differences that NVME_HOST_AUTH makes and visible > > from userland. I found ctrl_dhchap_secret sysfs attribute of nvme devices is > > in #ifdef CONFIG_HOST_AUTH. But to find the attribute, it looks "nvme connect" > > needs to happen before-hand. So the attribute does not look usable. Hmm. > > I rethought about the ctrl_dhchap_secret sysfs attribute, and came up with an > idea to set up nvme target without host key and do "nvme connect". (With host > key, nvme connect fails). Then check if the sysfs attributes exists or not. > > I quickly created a patch below, and it looks working. The check creates a nvme > target and affects the test system, then I think it should be done in test() > rather than requires(). If there is no better idea, we can take this solution. I'd rather see this fixed as pointed out above. This is a lot of overhead to figure out if something is supported. Thanks, Daniel
