Messages in this thread | | | Date | Tue, 30 Mar 2021 20:30:22 +0200 | From | "" <> | Subject | Re: [RFC PATCH] nvme: allow NVME_IOCTL_IO_CMD on controller char dev even when multiple ns |
| |
On 26.03.2021 20:59, Niklas Cassel wrote: >From: Niklas Cassel <niklas.cassel@wdc.com> > >Currently when doing NVME_IOCTL_IO_CMD on the controller character device, >the command is rejected if there is more than one namespace in the >ctrl->namespaces list. > >There is not really any reason for this restriction. >Instead, check the nsid value specified in the passthru command, and try >to find the matching namespace in ctrl->namespaces list. >If found, call nvme_user_cmd() on the namespace. >If not found, reject the command. > >While at it, remove the warning that says that NVME_IOCTL_IO_CMD is >deprecated on the controller character device. >There is no comment saying why it is deprecated. >It might be very unsafe to send a passthru command, but if that is >the issue with this IOCTL, then we should add a warning about that >instead. > >Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
I think the idea is OK, but I have 3 questions:
1. Wouldn't this break user-space when nsid is not specified? 2. What is the use case for this? As I understand it, this char device is primarily for admin commands sent to the controller. Do you see a use case for sending commands to the namespace using the controller char device? 3. Following up on the above, if the use-case is I/O, don't you think it is cleaner to use the ongoing per-namespace char device effort? We would very much like to get your input there and eventually send a series together. When this is merged, we could wire that logic to the controller char device if there is an use-case for it.
Javier
| |