Hi,
This is the third version for the ynl and drivers/net/hw
cross-compilation enablement series.
Changes come from Sashiko reviews, that detected some Makefile inclusion
ordering issues, a stray 'Q = @' in the ynl makefiles to have proper
verbosity support, and some commit log rewording.
Changes in V3:
- Add Matthieu's review tags
- Drop 'Q = @' line in patch 1, it's now handled properly through
Makefile.include
- Include Makefile.include before Makefile.arch
- Reword the commit logs to explain the limitations
Changes in V2:
V2: https://lore.kernel.org/r/20260903155524.2241065-1-maxime.chevallier@bootlin.com
- Update the topic for patch 1
- Update the CC construction for patch 2
V1: https://lore.kernel.org/r/20260901164200.1124343-1-maxime.chevallier@bootlin.com
Maxime Chevallier (Netdev Foundation) (2):
tools: ynl: Allow cross-compiling ynl and associated tools
selftests: drv-net: Use cross-compilation environment for the io_uring
check
tools/net/ynl/Makefile | 1 +
tools/net/ynl/generated/Makefile | 3 ++-
tools/net/ynl/lib/Makefile | 3 ++-
tools/net/ynl/tests/Makefile | 2 +-
tools/net/ynl/ynltool/Makefile | 6 ++----
tools/testing/selftests/drivers/net/hw/Makefile | 5 +++++
6 files changed, 13 insertions(+), 7 deletions(-)
--
2.55.0
The ynl tool and libraries may be built standalone or through the
drivers/net/hw selftest machinery. This may target a different arch, so
we need to take the CROSS_COMPILE variable into account for LLVM and
gcc.
Let's include the tools/scripts/Makefile.include that deals with the
CC/AR resolution.
Fixup the ynltool CFLAGS handling to use +=, so that we don't override
the ones set in Makefile.include.
Makefile.include also sets the Q variable for verbose mode, so we can
drop it from the ynltool Makefile. This will allow properly selection
the verbosity of ynltool builds with the V=1 make flag.
Reviewed-by: Matthieu Baerts (Netdev Foundation) <matttbe@kernel.org>
Signed-off-by: Maxime Chevallier (Netdev Foundation) <maxime.chevallier@bootlin.com>
---
tools/net/ynl/Makefile | 1 +
tools/net/ynl/generated/Makefile | 3 ++-
tools/net/ynl/lib/Makefile | 3 ++-
tools/net/ynl/tests/Makefile | 2 +-
tools/net/ynl/ynltool/Makefile | 6 ++----
5 files changed, 8 insertions(+), 7 deletions(-)
To test for the presence of zerocopy support in the available liburing,
a small check program is compiled.
The CC value used for the io_uring library check defaults to the host
compiler, which will incorrectly validate liburing based on the host's
sysroot and not the target's.
Normally the CC for cross-compile is set in lib.mk, but this also
requires the test list to be set when we include it, and this check
needs to run first.
Note that this doesn't cover the LLVM cross-compiling case though, as
with LLVM we may still detect based on the host liburing.
Suggested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Matthieu Baerts (Netdev Foundation) <matttbe@kernel.org>
Signed-off-by: Maxime Chevallier (Netdev Foundation) <maxime.chevallier@bootlin.com>
---
tools/testing/selftests/drivers/net/hw/Makefile | 5 +++++
1 file changed, 5 insertions(+)
@@ -1,5 +1,10 @@# SPDX-License-Identifier: GPL-2.0+ OR MIT+# Set CC for the io_uring check+ifeq ($(LLVM)$(CC),cc)+CC:=$(CROSS_COMPILE)gcc+endif+# Check if io_uring supports zero-copy receiveHAS_IOURING_ZCRX:=$(shell\echo-e'#include <liburing.h>\n'\
Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider:
Critical: 0 · High: 0 · Medium: 2 · Low: 0
- [Medium] tools/net/ynl/ynltool/Makefile now inherits the tools/ `O=` ->
`OUTPUT` contract from tools/scripts/Makefile.include but only half-…
- [Medium] Removing the `CC=gcc` pin while letting Makefile.include
select clang makes the GCC-only `-static-libasan` flag reach clang,…
--
tools: ynl: Allow cross-compiling ynl and associated tools
The four ynl Makefiles now include tools/scripts/Makefile.include so that
CC and AR honour CROSS_COMPILE and LLVM, the ynltool CFLAGS assignment is
switched from := to += and the local Q definition is dropped in favour of
the one from Makefile.include.
No Link: tags in the commit header.
Two questions below, one about O= handling in ynltool and one about
-static-libasan now that CC is no longer pinned to gcc.
@@ -2,8 +2,8 @@# Makefile for YNL testsinclude ../Makefile.deps+include ../../../scripts/Makefile.include-CC=gcc
[Severity: Medium]
With the CC=gcc pin removed here, does a "make LLVM=1 -C tools/net/ynl"
build still complete? Makefile.include picks clang for LLVM builds:
ifneq ($(LLVM),)
...
$(call allow-override,CC,$(LLVM_PREFIX)clang$(LLVM_SUFFIX))
and tests/Makefile turns the sanitizer flags on unless NDEBUG=1:
ifneq ("$(NDEBUG)","1")
CFLAGS += -g -fsanitize=address -fsanitize=leak -static-libasan
endif
clang's driver does not accept -static-libasan. Other selftests Makefiles
guard exactly this flag, for example
tools/testing/selftests/filesystems/openat2/Makefile:
# gcc requires -static-libasan in order to ensure that Address Sanitizer's
# library is the first one loaded. However, clang already statically links the
# Address Sanitizer if -fsanitize is specified. Therefore, simply omit
# -static-libasan for clang builds.
ifeq ($(LLVM),)
CFLAGS += -static-libasan
endif
tests is listed in SUBDIRS of tools/net/ynl/Makefile and the default goal
is "all: $(SUBDIRS) libynl.a", so this is hit by a plain build with LLVM=1
(with or without CROSS_COMPILE, which is the configuration named in the
commit message).
The same unguarded flag sits on the DEBUG=1 paths of lib/Makefile,
generated/Makefile and ynltool/Makefile. Should all four get the
ifeq ($(LLVM),) guard as part of this change?
[Severity: Medium]
Does pulling Makefile.include in here break "make O=<dir>" for ynltool?
Makefile.include translates a command line O= into OUTPUT:
ifneq ($(O),)
ifeq ($(origin O), command line)
$(if $(shell cd $(PWD); test -d $(O) || echo $(O)),$(error O=$(O) does not exist),)
ABSOLUTE_O := $(shell cd $(PWD); cd $(O) ; pwd)
OUTPUT := $(ABSOLUTE_O)/$(if $(subdir),$(subdir)/)
ynltool/Makefile already names its targets with that prefix:
OBJS := $(patsubst %.c,$(OUTPUT)%.o,$(SRCS))
YNLTOOL := $(OUTPUT)ynltool
but the only object rule carries no $(OUTPUT) and does not create the
directory:
%.o: %.c ../libynl.a
$(Q)echo -e "\tCC $@"
$(Q)$(COMPILE.c) -MMD -c -o $@ $<
For a target such as /tmp/out/ynl.o and a target pattern containing no
slash, make strips the directory, matches the stem, and re-prepends the
directory to the derived prerequisite, so it looks for /tmp/out/ynl.c.
There is no vpath and nothing creates /tmp/out, so does
"make -C tools/net/ynl/ynltool O=/tmp/out" stop with "No rule to make
target '/tmp/out/<name>.o', needed by '/tmp/out/ynltool'"?
Command line variables propagate through MAKEFLAGS, and the top level
recipe runs the sub-makes with
$(SUBDIRS):
@if [ -f "$@/Makefile" ] ; then \
$(MAKE) -C $@ ; \
fi
so "make -C tools/net/ynl O=/tmp/out" reaches the same path through the
default goal. Other tools/ Makefiles that honour this interface spell the
rule as $(OUTPUT)%.o: %.c - would that plus an mkdir be the fix here?
The install rule interpolates the prefixed name too:
install: $(YNLTOOL)
$(INSTALL) -m 0755 $(YNLTOOL) $(DESTDIR)$(bindir)/$(YNLTOOL)
With OUTPUT set, does the destination become
$(DESTDIR)/usr/bin//tmp/out/ynltool rather than $(DESTDIR)/usr/bin/ynltool?
Related: lib/Makefile, generated/Makefile and tests/Makefile now include
Makefile.include but ignore OUTPUT entirely, so an O= build would keep
writing their objects into the source tree while only ynltool tries to
honour it. Was leaving the four sub-makefiles inconsistent about O=
intentional, or should O= be rejected until they all handle it?
Thank you for your contribution! Sashiko AI review found 2 potential
issue(s) to consider:
Critical: 0 · High: 0 · Medium: 1 · Low: 1
- [Medium] Incomplete fix: the new guard `ifeq ($(LLVM)$(CC),cc)` in
tools/testing/selftests/drivers/net/hw/Makefile only overrides CC when…
- [Low] Missing `Fixes:` tag.
--
selftests: drv-net: Use cross-compilation environment for the io_uring check
This sets CC to $(CROSS_COMPILE)gcc in the drivers/net/hw selftests
Makefile before the liburing feature probe runs, so that the probe uses the
target toolchain instead of the host compiler. The override is applied only
when make's CC is still the built-in default and LLVM is unset.
No Link: tag present in the commit header.
@@ -1,5 +1,10 @@# SPDX-License-Identifier: GPL-2.0+ OR MIT+# Set CC for the io_uring check+ifeq ($(LLVM)$(CC),cc)+CC:=$(CROSS_COMPILE)gcc+endif
[Severity: Medium]
Does this condition cover the case where CC comes from the environment
rather than from make's built-in default?
With something like:
export CC=gcc-13
make -C tools/testing/selftests/drivers/net/hw CROSS_COMPILE=aarch64-linux-gnu-
$(LLVM)$(CC) expands to gcc-13, so the override is skipped and the probe
below runs the host gcc-13. Later, lib.mk does:
tools/testing/selftests/lib.mk:
ifneq ($(LLVM),)
CC := $(CLANG) $(CLANG_FLAGS) -fintegrated-as
else
CC := $(CROSS_COMPILE)gcc
endif # LLVM
Since that is a := assignment in a makefile, it overrides the
environment-origin CC, so the compiler that actually links iou-zcrx is not
the one that was probed.
Would an origin test such as:
ifeq ($(origin CC),default)
or mirroring lib.mk's own ifneq ($(LLVM),) ... else CC := $(CROSS_COMPILE)gcc
structure (as tools/testing/selftests/arm64/mte/Makefile does) make both
sides agree, and also close the LLVM case noted in the commit message?
[Severity: Low]
Should this carry a Fixes: tag?
git blame on the baseline attributes the whole probe block, including the
$(CC) -luring invocation and the COND_GEN_FILES += iou-zcrx gate, to:
f81171fecd0c ("selftests: hw-net: auto-disable building the iouring C code")
Before that commit there was no CC-dependent probe in this Makefile. Adding
the tag would let backporters pick this up into trees that already carry
f81171fecd0c.
[Severity: Medium]
Related to the CC question above: the probe invokes only $(CC) -luring and
passes none of CFLAGS/CPPFLAGS/LDFLAGS/USERCFLAGS/USERLDFLAGS, while the
generic C rule in lib.mk does pass them when linking $(OUTPUT)/iou-zcrx.
Can a target liburing that is only reachable through user-supplied
-I/-L/sysroot flags stay invisible to this probe?
The two failure modes both come from the probe answering for a different
toolchain than the build:
ifeq ($(HAS_IOURING_ZCRX),y)
$(OUTPUT)/iou-zcrx: LDLIBS += -luring
endif
Host-only liburing gives y and the cross link of iou-zcrx then fails on
-luring, taking the whole drivers/net/hw build with it. Target-only liburing
gives an empty value and the test is dropped with the warning "excluding
iouring tests, liburing not installed or too old".
[ ... ]
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260907161438.755125-1-maxime.chevallier%40bootlin.com
From: Jakub Kicinski <kuba@kernel.org> Date: 2026-09-09 00:30:32
On Mon, 7 Sep 2026 18:14:34 +0200 Maxime Chevallier (Netdev
Foundation) wrote:
Changes come from Sashiko reviews, that detected some Makefile inclusion
ordering issues, a stray 'Q = @' in the ynl makefiles to have proper
verbosity support, and some commit log rewording.
Looks good enough, if it works for you.
If we see a lot of follow ups and variance in the env people want
to support we'll have to add some kind of a build test env on QEMU.
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski [off-list ref]:
On Mon, 7 Sep 2026 18:14:34 +0200 you wrote:
Hi,
This is the third version for the ynl and drivers/net/hw
cross-compilation enablement series.
Changes come from Sashiko reviews, that detected some Makefile inclusion
ordering issues, a stray 'Q = @' in the ynl makefiles to have proper
verbosity support, and some commit log rewording.
[...]
From: Bobby Eshleman <hidden> Date: 2026-09-09 01:12:00
On Mon, Sep 07, 2026 at 06:14:35PM +0200, Maxime Chevallier (Netdev Foundation) wrote:
The ynl tool and libraries may be built standalone or through the
drivers/net/hw selftest machinery. This may target a different arch, so
we need to take the CROSS_COMPILE variable into account for LLVM and
gcc.
Let's include the tools/scripts/Makefile.include that deals with the
CC/AR resolution.
Fixup the ynltool CFLAGS handling to use +=, so that we don't override
the ones set in Makefile.include.
Makefile.include also sets the Q variable for verbose mode, so we can
drop it from the ynltool Makefile. This will allow properly selection
the verbosity of ynltool builds with the V=1 make flag.
Reviewed-by: Matthieu Baerts (Netdev Foundation) <matttbe@kernel.org>
Signed-off-by: Maxime Chevallier (Netdev Foundation) <maxime.chevallier@bootlin.com>
Hey Maxime,
It seems that this patch may break some invocations of make:
# make -C tools/net/ynl/ynltool O=/tmp/o1
make: Entering directory '/data/users/bobbyeshleman/linux-worktrees/review/tools/net/ynl/ynltool'
make: *** No rule to make target '/tmp/o1/json_writer.o', needed by '/tmp/o1/ynltool'. Stop.
make: Leaving directory '/data/users/bobbyeshleman/linux-worktrees/review/tools/net/ynl/ynltool'
Best,
Bobby
From: Maxime Chevallier <maxime.chevallier@bootlin.com> Date: 2026-09-09 07:02:08
Hi,
On 9/9/26 03:11, Bobby Eshleman wrote:
On Mon, Sep 07, 2026 at 06:14:35PM +0200, Maxime Chevallier (Netdev Foundation) wrote:
quoted
The ynl tool and libraries may be built standalone or through the
drivers/net/hw selftest machinery. This may target a different arch, so
we need to take the CROSS_COMPILE variable into account for LLVM and
gcc.
Let's include the tools/scripts/Makefile.include that deals with the
CC/AR resolution.
Fixup the ynltool CFLAGS handling to use +=, so that we don't override
the ones set in Makefile.include.
Makefile.include also sets the Q variable for verbose mode, so we can
drop it from the ynltool Makefile. This will allow properly selection
the verbosity of ynltool builds with the V=1 make flag.
Reviewed-by: Matthieu Baerts (Netdev Foundation) <matttbe@kernel.org>
Signed-off-by: Maxime Chevallier (Netdev Foundation) <maxime.chevallier@bootlin.com>
Hey Maxime,
It seems that this patch may break some invocations of make:
# make -C tools/net/ynl/ynltool O=/tmp/o1
make: Entering directory '/data/users/bobbyeshleman/linux-worktrees/review/tools/net/ynl/ynltool'
make: *** No rule to make target '/tmp/o1/json_writer.o', needed by '/tmp/o1/ynltool'. Stop.
make: Leaving directory '/data/users/bobbyeshleman/linux-worktrees/review/tools/net/ynl/ynltool'
Indeed, but looks like the command you're mentionning never worked as expected in the
first place, passing O=/tmp/xxx triggers the bug, but before the patch, O=/tmp/xxx
just does nothing, out-of-tree build just never worked for ynltool :
Before this patch :
$ make -C tools/net/ynl/ynltool O=/tmp/o1 V=1
make: Entering directory '/home/mchevallier/work/netdev/linux/tools/net/ynl/ynltool'
CC json_writer.o
CC main.o
CC page-pool.o
CC qstats.o
LINK ynltool
make: Leaving directory '/home/mchevallier/work/netdev/linux/tools/net/ynl/ynltool'
$ ls /tmp/o1/
$
The fix is simple though:
-%.o: %.c ../libynl.a
+$(OUTPUT)%.o: %.c ../libynl.a
I'll send the followup rightaway.
Side-note, out-of-tree build doesn't work for other ynl tools and utilities, but at least
trying to do so doesn't error-out.
Thanks for the report,
Maxime