[PATCH v4 2/6] Add GPIO ioctl decoding

[Kent Gibson]

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.

Otherwise go ahead with your ldv/gpio branch.

Cheers,
Kent.