[PATCH v4 2/6] Add GPIO ioctl decoding

Kent Gibson warthog618 at gmail.com
Tue Feb 2 02:46:36 UTC 2021


On Tue, Feb 02, 2021 at 05:03:48AM +0300, Dmitry V. Levin wrote:
> On Sat, Jan 30, 2021 at 10:30:33AM +0800, Kent Gibson wrote:
> > On Tue, Jan 26, 2021 at 05:40:27PM +0300, Dmitry V. Levin wrote:
> > > On Tue, Jan 26, 2021 at 07:01:00AM +0800, Kent Gibson wrote:
> > > > On Mon, Jan 25, 2021 at 04:23:43PM +0300, Dmitry V. Levin wrote:
> > > > > On Mon, Jan 25, 2021 at 05:44:50AM +0300, Dmitry V. Levin wrote:
> > > > > > On Mon, Jan 25, 2021 at 09:48:38AM +0800, Kent Gibson wrote:
> > > > > > [...]
> > > > > > > What I'm suggesting is keeping a copy of the current linux/gpio.h in the
> > > > > > > strace tree so we always build against that - even when building on old
> > > > > > > kernels.  The decoder and tests would match that specific header, but
> > > > > > > build on any kernel.
> > > > > > > 
> > > > > > > Granted this doesn't work for any headers that may have ABI issues, but
> > > > > > > that isn't the case for gpio.h - all the types have remained ABI
> > > > > > > compatible since inception.  And that is why we needed to do a v2 as
> > > > > > > those types were unable to be extended.
> > > > > > > 
> > > > > > > The biggest problem I have is where to put it, as the types directory
> > > > > > > serves a different purpose.
> > > > > > 
> > > > > > Yes, this is technically possible to place it into "linux/gpio.h".
> > > > > > The license of this header is "GPL-2.0 WITH Linux-syscall-note" which
> > > > > > means that it "can be included into non GPL compliant user space
> > > > > > application code", so I don't see any license issues here. 
> > > > > > 
> > > > > > This was not always the case, before commit v4.14-rc8~25^2 the license of
> > > > > > linux/gpio.h was GPL-2.0-only (i.e. without Linux-syscall-note exception)
> > > > > > which meant it couldn't be included without making the whole project
> > > > > > GPL-2.0-only.
> > > > > > 
> > > > > > Maybe it's time to reconsider our policy of not copying Linux header
> > > > > > files.
> > > > > 
> > > > > However, since the intent of the Linux-syscall-note exception was to allow
> > > > > the header file to be #include'd by non-GPL-2.0 software, I'm not sure that
> > > > > this exception also grants permission to copy the header file into a
> > > > > non-GPL-2.0 software project.
> > > > 
> > > > Agreed - even the Linux developers seem to be unclear on this point[1],
> > > > so we can't copy the header without something more definitive as to
> > > > how the licence applies in this case.
> > > > 
> > > > I've raised the issue in the GPIO mailing list and will continue to
> > > > follow up on it until we get an answer.  If we don't get a positive
> > > > response reasonably promptly we'll have to go with your ldv/gpio
> > > > branch solution.
> > > 
> > > Yes, I'm inclined to follow the ldv/gpio branch approach.
> > > Should the situation change in favour of copying of uapi header files,
> > > we could easily drop types/gpio.h and switch to a more simple scheme.
> > > 
> > As per the thread in the GPIO mailing list, I think we're good to copy
> > the kernel headers into the repo.  If you'd like to take that option let
> > me know where you'd like them located and I'll rework my patches to
> > suite.
> 
> Thanks for your research [1], it looks like we can bundle unmodified
> Linux uapi headers with strace.  In short, we would have to:
> - create a directory for these bundled files,
> - add a COPYING file there as well as a copy of GPL-2.0 and
>   Linux-syscall-note files, 
> - update the main COPYING file with a statement that files in that
>   directory are distributed under the terms of GPL-2.0 WITH
>   Linux-syscall-note as explained in the corresponding COPYING file,
> - update include path to make sure that header files in that directory
>   are used instead of system uapi headers.
> 
> What's lacking is the name for that directory.  While many projects bundle
> various bits and pieces, I'm not sure there is an established tradition
> for the name of such directory.
> 

Indeed - naming is frequently the hardest part.
You already use "linux" for local versions of some headers so that is
out.
libgpiod currently uses "uapi" as the directory name, but that roughly
maps to linux/include/uapi/linux/ and so only includes uAPI headers and
there may be other parts of the include tree that you want to bundle for
strace.  And that is only a recent addition and may change given [1].

Earlier in that thread Bart identified several projects that already
bundle: 

"It turns out most projects simply package the uapi headers together
with their sources (e.g. wpa_supplicant, libnl, iproute2) to avoid
complicated dependencies."

but I doubt they keep the sources separated to the extent I have
suggested, much less use a consistent naming scheme.

Sorry - not being much help here...

> [1] https://lore.kernel.org/linux-gpio/20210128032641.GA11655@sol/
> 
> > Otherwise go ahead with your ldv/gpio branch.
> 
> To be honest, I've got a few dozens of commits on top of ldv/gpio changing
> various aspects of printing, so for now I'd rather go ahead with what's
> already tested, and cleanup later when the bundling infrastructure is
> ready for use.
> 

Fair enough - I imagine switching over to bundled kernel headers is a
massive task in itself and there is no hurry to switch.

So whatever works for you.

Cheers,
Kent.


More information about the Strace-devel mailing list