On 9/9/24 02:02, Stephen Hemminger wrote:
On Fri, 6 Sep 2024 00:15:26 +0200
Maxime Coquelin <maxime.coque...@redhat.com> wrote:
This patch introduces uAPI headers importation into the
DPDK repository. This import is possible thanks to Linux
Kernel licence exception for syscalls:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/LICENSES/exceptions/Linux-syscall-note
Header files are have to be explicitly imported, and
libraries and drivers have to explicitly enable their
inclusion.
Guidelines are provided in the documentation, and a helper
script is also provided to ensure proper importation of the
header (unmodified content from a released Kernel version).
Next version will introduce a script to check headers are
valids.
Signed-off-by: Maxime Coquelin <maxime.coque...@redhat.com>
---
devtools/import-linux-uapi.sh | 48 ++++++++++++++++++++
doc/guides/contributing/index.rst | 1 +
doc/guides/contributing/linux_uapi.rst | 63 ++++++++++++++++++++++++++
meson.build | 4 ++
4 files changed, 116 insertions(+)
create mode 100755 devtools/import-linux-uapi.sh
create mode 100644 doc/guides/contributing/linux_uapi.rst
diff --git a/devtools/import-linux-uapi.sh b/devtools/import-linux-uapi.sh
new file mode 100755
index 0000000000..efeffdd332
--- /dev/null
+++ b/devtools/import-linux-uapi.sh
@@ -0,0 +1,48 @@
+#!/bin/sh -e
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright (c) 2024 Red Hat, Inc.
+
+#
+# Import Linux Kernel uAPI header file
+#
+
+base_url="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/uapi/";
+base_path="linux-headers/uapi/"
Sorry, not a fan of this.
This must be optional. Most other projects don't do this and it risks
incompatibilities with the C library.
QEMU, libgpio at least do this.
Supporting new features is quite a mess in lib Vhost currently, because
we cannot know what is and what is not defined in the build OS headers.
For example:
https://github.com/DPDK/dpdk/blob/main/lib/vhost/vhost.h#L369
Did you make sure the headers are exactly the same as the distro uses (for the
same kernel version).
Worried that this is not the exact same process that "make headers_install"
might use.
We could have them picked from make headers_install. It would be heavier
to do, but could be done if you see any difference.
Also, ideally the tool would be selective.
Selective about what?
Note that this current RFC is too simplistic, it misses nested headers
import. Will try to cover this in nect revision.
Thanks,
Maxime
