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