Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200814030257.135463-1-warthog618@gmail.com> <CAMpxmJUCwXVv6U9sE=8isRMoNd8QvM9XLu4PU2Rr454wt_FTUw@mail.gmail.com>
 <20200817184018.GV1891694@smile.fi.intel.com>
In-Reply-To: <20200817184018.GV1891694@smile.fi.intel.com>
From:   Bartosz Golaszewski <bgolaszewski@baylibre.com>
Date:   Mon, 17 Aug 2020 21:25:30 +0200
Message-ID: <CAMpxmJV6k=mQaYsH_abTHhyXis+hLJkJX+M9jAtciUB=0uoEUA@mail.gmail.com>
Subject: Re: [PATCH v4 00/20] gpio: cdev: add uAPI v2
To:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc:     Kent Gibson <warthog618@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>,
        linux-gpio <linux-gpio@vger.kernel.org>,
        Linus Walleij <linus.walleij@linaro.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Aug 17, 2020 at 8:40 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> 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@gmail.com> 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