On Tue, 3 Mar 2026, Warner Losh wrote:
On Tue, Mar 3, 2026 at 11:29 AM Bjoern A. Zeeb <[email protected]> wrote:
On Tue, 3 Mar 2026, Enji Cooper wrote:
The branch main has been updated by ngie:
URL:
https://cgit.FreeBSD.org/src/commit/?id=c47cefba831240a1b3de375f18134b93cf998f5c
commit c47cefba831240a1b3de375f18134b93cf998f5c
Author: Enji Cooper <[email protected]>
AuthorDate: 2026-03-03 04:49:54 +0000
Commit: Enji Cooper <[email protected]>
CommitDate: 2026-03-03 04:50:03 +0000
Only build USB-related modules if MK_USB != no
This change moves the thunderbolt module and other USB modules under a
MK_USB != no conditional to ensure that users not desiring USB support
can easily build systems without USB-specific drivers using this knob.
MFC after: 1 week
Reviewed By: imp
Differential Revision: https://reviews.freebsd.org/D55576
---
sys/conf/kern.opts.mk | 5 +++++
sys/conf/kmod.mk | 8 ++++++--
sys/modules/Makefile | 16 ++++++++++------
3 files changed, 21 insertions(+), 8 deletions(-)
There is a hige load of further devices which depend on USB which are not
part of the current set excluded; I assume they will now break with
dependency
issues if USB is no longer built but these modules are built.
Is there any plan to also "hide" all the other modules?
As I said in my review, I'm generally uneasy about this trend...
I never got that far as the review diff I looked at was broken at that point.
This may also be wrong:
% ls -l tools/build/options/*USB*
-rw-r--r-- 1 bz bz 49 Mar 21 2025 tools/build/options/WITHOUT_USB
-rw-r--r-- 1 bz bz 40 Mar 21 2025
tools/build/options/WITHOUT_USB_GADGET_EXAMPLES
-rw-r--r-- 1 bz bz 33 Mar 21 2025 tools/build/options/WITH_USB_GADGET_EXAMPLES
% cat tools/build/options/WITHOUT_USB
Do not build USB-related programs and libraries.
Usually we used to have a FOO_SUPPORT which would then also not build kernel
modules or not build FOO suport into (programs, libraries, and) kernel modules,
e.g. INET, INET6, NETGRAPH.
Though, unless INET and INET6 started to become loadable seems wrong these days
and I'd use a check based on the kernel config (which I believe came years later
as an option) and remove the entire MK_INET[6]_SUPPORT checks for the kernel.
The NETGRAPH example is a bad one as it seems to be unimplemeted for the kernel
side so NETGRAPH_SUPPORT description is misleading.
USB tends to be more tricky as it is fully loadable but then then answer
for people who don't want a system supporting USB would mean removing
all the modules (which we cannot do based on the kernel config).
The question then remains whether a src.conf based knob is the right
thing and which one it should be. MK_USB seems wrong but more knobs do
not make it better as we have too many of them these days if you ask me.
The answer may simply be to rm the modules if a system does not want/need
them. I kind-of see that as a rare special-case problem and if someone
really needs to ship a system like that then they may have to go the
extra length and maintain that bit?
If we were really to support this in the build system then we should make
sure that all USB modules are no longer build.
Given I had my fingers in the USB modules list (though not the full one)
recently "uneasy" is maybe not enough for the feeling in my stomach.
/bz
--
Bjoern A. Zeeb r15:7
