On Wed, Jun 11, 2025 at 10:15:37PM -0700, Christoph Hellwig wrote:
> On Wed, Jun 11, 2025 at 12:23:00PM +0200, Christian Brauner wrote:
> > > +struct logical_block_metadata_cap {
> > > + __u32 lbmd_flags;
> > > + __u16 lbmd_interval;
> > > + __u8 lbmd_size;
> > > + __u8 lbmd_opaque_size;
> > > + __u8 lbmd_opaque_offset;
> > > + __u8 lbmd_pi_size;
> > > + __u8 lbmd_pi_offset;
> > > + __u8 lbmd_guard_tag_type;
> > > + __u8 lbmd_app_tag_size;
> > > + __u8 lbmd_ref_tag_size;
> > > + __u8 lbmd_storage_tag_size;
> > > + __u8 lbmd_rsvd[17];
> >
> > Don't do this hard-coded form of extensiblity. ioctl()s are inherently
> > extensible because they encode the size. Instead of switching on the
> > full ioctl, switch on the ioctl number. See for example fs/pidfs:
>
> Umm, yes and no. The size encoding in the ioctl is great. But having
> a few fields in a structure that already has flags allows for much
> easier extensions for small amounts of data. Without the reserved
> fields, this structure is 15 bytes long. So we'll need at least 1
> do pad to a natural alignment. I think adding another 16 (aka
> two u64s) seems pretty reasonable for painless extensions.
I'm really against having structures that can't simply grow as needed in
2025. That has bitten us so often I don't see the point in perpetuating
this fixed-size stuff especially since userspace is very very used to
this extensibility by now. And also because you don't have to
pointlessly copy data you don't need in and out of the kernel on
principle alone.
