Thread (36 messages) 36 messages, 3 authors, 2020-08-18

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

From: Bartosz Golaszewski <hidden>
Date: 2020-08-17 19:25:59
Also in: lkml

On Mon, Aug 17, 2020 at 8:40 PM Andy Shevchenko
[off-list ref] wrote:
On Mon, Aug 17, 2020 at 08:24:24PM +0200, Bartosz Golaszewski wrote:
quoted
On Fri, Aug 14, 2020 at 5:03 AM Kent Gibson [off-list ref] wrote:
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help