On Tue, Dec 13, 2022 at 04:58:47AM +0000, Chaitanya Kulkarni wrote: > Michael, > > On 12/7/22 12:28, Michael S. Tsirkin wrote: > > On Wed, Dec 07, 2022 at 08:31:28AM -0800, Christoph Hellwig wrote: > >> On Wed, Dec 07, 2022 at 05:21:48AM -0500, Michael S. Tsirkin wrote: > >>> Christoph you acked the spec patch adding this to virtio blk: > >>> > >>> Still not a fan of the encoding, but at least it is properly documented > >>> now: > >>> > >>> Acked-by: Christoph Hellwig <hch@xxxxxx> > >>> > >>> Did you change your mind then? Or do you prefer a different encoding for > >>> the ioctl then? could you help sugesting what kind? > >> > >> Well, it is good enough documented for a spec. I don't think it is > >> a useful feature for Linux where virtio-blk is our minimum viable > >> paravirtualized block driver. > > > > No idea what this means, sorry. Now that's in the spec I expect (some) > > devices to implement it and if they do I see no reason not to expose the > > data to userspace. > > > > Even if any device implements is it can always use passthru commands. > See below for more info... > > > Alvaro could you pls explain the use-case? Christoph has doubts that > > it's useful. Do you have a device implementing this? > > > > From what I know, virtio-blk should be kept minimal and should not > add any storage specific IOCTLs or features that will end up loosing > its generic nature. > > The IOCTL we are trying to add is Flash storage specific which > goes against the nature of generic storage and makes it non-generic. > In case we approve this it will open the door for non-generic > code/IOCTL in the virtio-blk and that needs to be avoided. Wrt these fields that horse has bolted, it's in the spec. > For any storage specific features or IOCTL (flash/HDD) it should > be using it's own frontend such as virtio-scsi or e.g. nvme and > not virtio-blk. > > Hope this helps. > > -ck I don't understand what you are suggesting, sorry. It's a hardware device. It can't just "switch to a different frontend". -- MST
