[PATCH v4 2/6] Add GPIO ioctl decoding

[Dmitry V. Levin]

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.


-- 
ldv