I must say, you did a damn good job. I'm still wading though the rewrite of this example and one stroke of brilliance in V2 I'm still figuring out is the attribute and attribute config which I'm using to define the base flags for writing (I have the write pin as line request offsets[0] and the read pin as offsets[1]) and then a line attribute and mask for the read flags. That will indeed add a great deal of flexibility. (at least in the way I'm trying to approach this with one line config and one line request struct to cover all pins and then using the attributes and values struct and mask to carry out the operations and set values on each pin)It is all in there - v2 is a strict super-set of v1. v1 grew organically and when I came along wanting to add debounce there was nowhere in the existing ioctls to put it. As new ioctls were in order it seemed like a good time to do a clean sweep and fix a bunch of other problems - like the odd object model that v1 had developed, e.g. edge detection requiring a separate request, and that only supporting a single line.
The v2 ioctls could be considered a bit convoluted, particularly as we've tried to allow for future features without breaking ABI compatibility (from now on), but the new object model and ioctls are much more flexible than v1. Some would argue too flexible. Hopefully the kernel documentation that I added recently will help clear up how to use them. There are docs for the v1 as well - if you want to compare.
If the attributes and mask work in the same manner as values .bits and .mask, then all should be good. Convoluted in what kernel developers do best -- and it all works amazingly well -- but it does lead to a lot of head scratching as you make friends with the ABI. The debounce will be icing on the cake.
Statistics: Posted by drankinatty — Thu May 09, 2024 8:46 am
