# cp sys/amd64/conf/GENERIC sys/amd64/conf/GENERIC-NONETLINK # echo "nooptions NETLINK" >> sys/amd64/conf/GENERIC-NONETLINK # make KERNCONF=GENERIC-NONETLINK WITHOUT_MODULES=yes -j$(nproc) buildkernel [...] --- netlink_generic_kpi.o --- ctfconvert -L VERSION -g netlink_generic_kpi.o --- netlink_glue.o --- /usr/src/sys/netlink/netlink_glue.c:285:15: error: no member named 'nl_modify_ifp' in 'struct nl_function_wrapper' return (_nl->nl_modify_ifp(ifp, lattrs, bm, npt)); ~~~ ^ /usr/src/sys/netlink/netlink_glue.c:282:1: error: no previous prototype for function 'nl_modify_ifp_generic' [-Werror,-Wmissing-prototypes] nl_modify_ifp_generic(struct ifnet *ifp, struct nl_parsed_link *lattrs, ^ /usr/src/sys/netlink/netlink_glue.c:281:1: note: declare 'static' if the function is not intended to be used outside of this translation unit int ^ static /usr/src/sys/netlink/netlink_glue.c:289:1: error: redefinition of 'nl_store_ifp_cookie_stub' nl_store_ifp_cookie_stub(struct nl_pstate *npt, struct ifnet *ifp) ^ /usr/src/sys/netlink/netlink_glue.c:189:1: note: previous definition is here nl_store_ifp_cookie_stub(struct nl_pstate *npt __unused, struct ifnet *ifp __unused) ^ 3 errors generated. *** [netlink_glue.o] Error code 1 make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NONETLINK
(In reply to throwaway_vthgwq4 from comment #0) You are probably missing WITHOUT_NETLINK_SUPPORT in make.conf
(In reply to Marek Zarychta from comment #1) No difference with and without {make,src}.conf. I started using WITHOUT_NETLINK_SUPPORT in src.conf after it was introduced.
Thanks for reporting! Will fix tomorrow.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=a1db1097e654272c1af0a1e0581b4a8deb75f168 commit a1db1097e654272c1af0a1e0581b4a8deb75f168 Author: Alexander V. Chernikov <melifaro@FreeBSD.org> AuthorDate: 2023-04-26 11:18:43 +0000 Commit: Alexander V. Chernikov <melifaro@FreeBSD.org> CommitDate: 2023-04-26 11:19:41 +0000 netlink: fix build without NETLINK in the kernel. PR: 271066 sys/netlink/netlink_glue.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
(In reply to throwaway_vthgwq4 from comment #2) Should be fixed by the commit mentioned above. While here - is there any chance you could share the reason of compiling everything without Netlink? This feedback will help me improve FreeBSD interfaces.
(In reply to Alexander V. Chernikov from comment #5) I confirm, base a1db1097e654 works fine here. Thanks for fixing. > the reason of compiling everything without Netlink? * Consistence with local ARM pkgbase builds, see: https://cgit.freebsd.org/src/tree/share/mk/src.opts.mk?id=a1db1097e654#n357 * None of NETLINK features are used here, so the feature gets disabled the same way as everything else not used locally (e.g. INET) as attack surface or kernel size reduction. Off-topic: aarch64 is Tier 1 nowadays, so should also be supported. Supporting i386 (not Tier 1 for >= 13), where native hardware belongs to museums, and COMPAT_FREEBSD32 is used for e.g. Wine or 4.0-RELEASE jails is hard to justify. If you want to test 32-bit, armv7 is arguably more relevant. NETLINK should also probably become machine-dependent as rtsock if it is to supersede rtsock.
(In reply to throwaway_vthgwq4 from comment #6) s/machine-dependent/machine-independent Sorry, I can't edit comments due to bug 191677.
(In reply to throwaway_vthgwq4 from comment #6) Thank you! That was really helpful and the arguments make a lot of sense. There was an extensive discussion on how we introduce Netlink in the kernel. After some back-and-forth, Netlink was added to the DEFAULTS options for each architecture. I completely forgot about the userland part and it ended up being in an intermediate state. I'll change it to be included by default on all architectures. Just in case: route(8), arp(8), ndp(8) and parts of netstat(8)/ifconfig(8) use Netlink instead of rtsock as a transport in -HEAD. The rtsock-based kernel functionality will continue to exist. The rtsock-based code in these utilities may be removed around FreeBSD 15, which leaves plenty of time. It may still be worth trying to eventually look at the Netlink versions, to ensure that nothing is broken in your workloads (the intent is to provide exactly the same functionality).