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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMpxmJV6k=mQaYsH_abTHhyXis+hLJkJX+M9jAtciUB=0uoEUA@mail.gmail.com>
Date:   Mon, 17 Aug 2020 21:25:30 +0200
From:   Bartosz Golaszewski <bgolaszewski@...libre.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Kent Gibson <warthog618@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-gpio <linux-gpio@...r.kernel.org>,
        Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH v4 00/20] gpio: cdev: add uAPI v2

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