On Tue, Mar 3, 2026 at 12:25 PM Bjoern A. Zeeb <[email protected]> wrote:
> 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. > Given all this, maybe we should revert this change and move the discussion to arch@. The USB vs USB_SUPPORT nails a lot of my uneasiness here. Warner
