Re: Include pieces of internal kernel header in GPL-3 project
* Jan Luca Naumann:
> Hey,
>
> the problem is that this structure was in a uapi header until Linux 4.4
> but it was replaced by a new header file in this kernel version. I'm not
> the upstream author of the code so I'm not sure if there is another way
> to access the functionality used in the software project. Of course you
> are right that it is a good idea to look for another kernel interface
> instead of copy the necessary structure to an own header file...
>
> Anyway, it would be interesting for me if this usage of pieces of a
> kernel header file is possible in GPL-3 project?
I can't comment on whether this is a licensing problem, but the
definitions were deliberately dropped:
commit 9d99a8dda154f38307d43d9c9aa504bd3703d596
Author: Christoph Hellwig <hch@lst.de>
Date: Fri Oct 2 15:25:49 2015 +0200
nvme: move hardware structures out of the uapi version of nvme.h
Currently all NVMe command and completion structures are exposed to userspac
e
through the uapi version of nvme.h. They are not an ABI between the kernel
and userspace, and will change in C-incompatible way for future versions of
the spec. Move them to the kernel version of the file and rename the uapi
header to nvme_ioctl.h so that userspace can easily detect the presence of
the new clean header. Nvme-cli already carries a local copy of the header,
so it won't be affected by this move.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Is the tool you are interested in very low-level? If not, per the
commit above, you really shouldn't need those struct definitions.
It may make sense to contact Keith Busch <keith.busch@intel.com> for
advice what to do here. If the definitions are part of the de-facto
kernel ABI, the kernel people should know about this.
Reply to: