Virtualization - Dec 2022 - [PATCH v2] virtio_blk: add VIRTIO_BLK_F_LIFETIME feature support

So, we could create a block-general lifetime ioctl with many reserved
bytes, or create a virtio block specific ioctl without reserved bytes
at all.
I think that we should keep it virtio specific, and if a new lifetime
command is added to the spec with more fields, we could create a new
ioctl.
Does Everyone agree?
> I think if you are going to pass struct virtio_blk_lifetime to
> userspace, better pass it as defined in the spec, in LE format.
> It's unusual for an ioctl to produce a struct that's not in CPU
> endianness. I think the kernel should deal with endianness here.
I'm not sure how to proceed with the endianness matter..

Alvaro

On Sun, Dec 04, 2022 at 10:19:38AM +0200, Alvaro Karsz
wrote:
> So, we could create a block-general lifetime ioctl with many reserved
> bytes, or create a virtio block specific ioctl without reserved bytes
> at all.

I don't see the connection. virtio would often pass through lifetime
info from the host. If other devices gain more info then it will make 
sense to add that to virtio, too.
> I think that we should keep it virtio specific, and if a new lifetime
> command is added to the spec with more fields, we could create a new
> ioctl.
> Does Everyone agree?
Depends. If we expect more types, then I think we
can solve this by passing an array of values.
> > I think if you are going to pass struct virtio_blk_lifetime to
> > userspace, better pass it as defined in the spec, in LE format.
> 
> > It's unusual for an ioctl to produce a struct that's not in
CPU
> > endianness. I think the kernel should deal with endianness here.
> 
> I'm not sure how to proceed with the endianness matter..
> 
> Alvaro
If it's a generic ioctl then clearly it's native.
For a virtio specific one, we typically use LE and I would be
consistent.

-- 
MST