[PATCH v4 2/6] Add GPIO ioctl decoding

[Kent Gibson]

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.

Hmmm, I thought API headers were open for copying either way.

> 
> Maybe it's time to reconsider our policy of not copying Linux header
> files.
> 

I'm was playing with your ldv/gpio branch, and have added the linux
gpio.h into types/linux/gpio.h, switched gpio_ioctl.c and ioctl_gpio.c
over to use those standard types, and removed types/gpio.h and
xlat/gpio_ioctl_cmds.in.

The result seems a whole lot simpler to me.

Btw, I went with types/linux/gpio.h to make the distinction between the
<linux/gpio.h> and "linux/gpio.h> clearer, but can easily relocate that.

I'll push a copy to my github later if you want to take a closer look
- other things have priority at the moment.

Cheers,
Kent.