On Tue, Nov 29, 2022 at 04:28:54AM +0000, Chaitanya Kulkarni wrote:
> On 11/28/22 11:07, Stefan Hajnoczi wrote:
> > On Fri, Nov 25, 2022 at 12:09:45AM +0200, Alvaro Karsz wrote:
> >>> I suggest defining a separate UAPI struct for this ioctl.
> >>
> >> Sounds fine to me.
> >> I could use the following struct
> >>
> >> struct virtio_blk_lifetime_ioctl {
> >> u16 pre_eol_info;
> >> u16 device_lifetime_est_typ_a;
> >> u16 device_lifetime_est_typ_b;
> >> u16 padding;
> >> };
> >
> > Looks good.
> >
> > Stefan
>
> with above definition how can one extend existing IOCTL to
> have new members in future ?
>
> e.g. from above structure
> type_a -> SLC
> type_b -> MLC
>
> so if someone wants to add type_c info for Quad-level cell(QLC)
> flash memory then type_d and so forth then how can this be
> achieved without adding a new IOCTL since ?
>
> OR
>
> just adding new members to user API ioctl struct will work
> fine ?
>
> -ck
>
You can do this since ioctl encodes the struct size.
But if that is envisioned then you don't really need padding.
--
MST
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
