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: <20200817184018.GV1891694@smile.fi.intel.com>
Date:   Mon, 17 Aug 2020 21:40:18 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Bartosz Golaszewski <bgolaszewski@...libre.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 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?

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?

-- 
With Best Regards,
Andy Shevchenko