On Wed, Sep 23, 2020 at 1:30 PM Kent Gibson <warthog618@xxxxxxxxx> wrote: > > On Wed, Sep 23, 2020 at 01:04:05PM +0300, Andy Shevchenko wrote: > > On Tue, Sep 22, 2020 at 5:34 AM Kent Gibson <warthog618@xxxxxxxxx> wrote: > > > > > [snip] > > > > There is also some minor renaming of fields for consistency compared to > > > their v1 counterparts, e.g. offset rather than lineoffset or line_offset, > > > and consumer rather than consumer_label. > > > > > > Additionally, v1 GPIOHANDLES_MAX becomes GPIO_V2_LINES_MAX in v2 for > > > clarity, and the gpiohandle_data __u8 array becomes a bitmap in > > > gpio_v2_line_values. > > > > > > The v2 uAPI is mostly a reorganisation and extension of v1, so userspace > > > code, particularly libgpiod, should readily port to it. > > > > ... > > > > > +struct gpio_v2_line_config { > > > + __aligned_u64 flags; > > > + __u32 num_attrs; > > > > > + /* Pad to fill implicit padding and reserve space for future use. */ > > > + __u32 padding[5]; > > > > Probably I somehow missed the answer, but why do we need 5 here and not 1? > > > > Sorry, I got tired of repeating myself, and just acked that we disagree > on the approach here. > > Your suggestion to use the size for version would result in an > explosion of ioctl signatures - every time we add a field we have to add > a new ioctl and handle it separately in gpio_ioctl() or linereq_ioctl(). No, you just add __u32 version; // implies sizeof() check as well. Look for examples of existing ABIs (e.g. perf ABI). > Instead what we do here is reserve some space for future use - that we > can replace with fields without changing the signature. > The padding is required to be zeroed now, and any future use will take > a 0 to mean "leave alone". > > The sizes are a guestimate as to what may be needed in the future, and > as such are almost certainly wrong - but hopefully on the high side. > If that fails we can always fall back to your approach. I see. So, we have no agreement on these pieces. Linus and Bart can decide what to do, but I think either way has pros and cons. So, guys, I am fine with everything else here, except this versioning issue and waste of resources. -- With Best Regards, Andy Shevchenko