Re: [PATCH v4 00/20] gpio: cdev: add uAPI v2

[Bartosz Golaszewski]

On Mon, Aug 17, 2020 at 8:40 PM Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
>
> On Mon, Aug 17, 2020 at 08:24:24PM +0200, Bartosz Golaszewski wrote:
> > On Fri, Aug 14, 2020 at 5:03 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > >
> > > This patchset defines and implements adds a new version of the
> > > GPIO CDEV uAPI to address existing 32/64-bit alignment issues, add
> > > support for debounce, event sequence numbers, and allowing for requested
> > > lines with different configurations.
> > > It provides some future proofing by adding optional configuration fields
> > > and padding reserved for future use.
> > >
> > > The series can be partitioned into two sets; the first eleven
> > > contain the v2 uAPI implementation, and the final seven port
> > > the GPIO tools to the v2 uAPI and extend them to use new uAPI features.
> > >
> > > The more complicated patches include their own commentary where
> > > appropriate.
>
> > The series looks quite good to me and I think we're on track to get it
> > in for v5.10. I'd love to have Andy (Cc'd) take a look as well. There
> > are some nits here and there but as long as we get the ABI right, any
> > implementation details can be ironed out later.
> >
> > I need to think about some details a bit more but I really like the
> > current state of the patches.
>
> First of all, I apologize for being silent, I'm quite busy with internal
> development / work.
>
> Second, I didn't hear further why we can't fix current ABI as proposed by Arnd
> and see what we will have afterwards?
>

Sure we can get back to fixing it but it will only address a single
bug and still not allow us to add new features and simplifications. Do
you mind rebasing your old patch on top of v5.9-rc1?

> Third, I'm not satisfied with the approach of wasting some memory for padding
> and I think the proper solution for the ABI is to have versioning inside the
> structures.
>
> What do you think?
>

Wasting a bit of memory is fine with me. As long as we're not copying
more than a page-worth of memory between the kernel and user-space,
the overhead is insignificant.

I prefer to make structs extensible over adding new versions in the future.

Bart