Date: Tue, 3 Mar 2026 12:47:16 -0700 From: Warner Losh <imp@bsdimp.com> To: "Bjoern A. Zeeb" <bz@freebsd.org> Cc: Enji Cooper <ngie@freebsd.org>, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: c47cefba8312 - main - Only build USB-related modules if MK_USB != no Message-ID: <CANCZdfojNLV5x_otOujYzvHYGx1Ge5Ywzq8BfQDaUEwWxt5sig@mail.gmail.com> In-Reply-To: <947orn62-43rq-383n-son8-90o6q2275os6@serrofq.bet> References: <69a668aa.3785e.4a16f236@gitrepo.freebsd.org> <1s9oq316-3q4o-9273-3qos-3n3o793ns725@mnoonqbm.arg> <CANCZdfpZFAZLNf7QhT0SLRX3=CM7aoFUcf4=Ois%2B37w5VED_mA@mail.gmail.com> <947orn62-43rq-383n-son8-90o6q2275os6@serrofq.bet>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Tue, Mar 3, 2026 at 12:25 PM Bjoern A. Zeeb <bz@freebsd.org> wrote: > On Tue, 3 Mar 2026, Warner Losh wrote: > > > On Tue, Mar 3, 2026 at 11:29 AM Bjoern A. Zeeb <bz@freebsd.org> 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 <ngie@FreeBSD.org> > >>> AuthorDate: 2026-03-03 04:49:54 +0000 > >>> Commit: Enji Cooper <ngie@FreeBSD.org> > >>> 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 [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Mar 3, 2026 at 12:25 PM Bjoern A. Zeeb <<a href="mailto:bz@freebsd.org">bz@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 3 Mar 2026, Warner Losh wrote:<br> <br> > On Tue, Mar 3, 2026 at 11:29 AM Bjoern A. Zeeb <<a href="mailto:bz@freebsd.org" target="_blank">bz@freebsd.org</a>> wrote:<br> ><br> >> On Tue, 3 Mar 2026, Enji Cooper wrote:<br> >><br> >>> The branch main has been updated by ngie:<br> >>><br> >>> URL:<br> >> <a href="https://cgit.FreeBSD.org/src/commit/?id=c47cefba831240a1b3de375f18134b93cf998f5c" rel="noreferrer" target="_blank">https://cgit.FreeBSD.org/src/commit/?id=c47cefba831240a1b3de375f18134b93cf998f5c</a><br>; >>><br> >>> commit c47cefba831240a1b3de375f18134b93cf998f5c<br> >>> Author: Enji Cooper <ngie@FreeBSD.org><br> >>> AuthorDate: 2026-03-03 04:49:54 +0000<br> >>> Commit: Enji Cooper <ngie@FreeBSD.org><br> >>> CommitDate: 2026-03-03 04:50:03 +0000<br> >>><br> >>> Only build USB-related modules if MK_USB != no<br> >>><br> >>> This change moves the thunderbolt module and other USB modules under a<br> >>> MK_USB != no conditional to ensure that users not desiring USB support<br> >>> can easily build systems without USB-specific drivers using this knob.<br> >>><br> >>> MFC after: 1 week<br> >>> Reviewed By: imp<br> >>> Differential Revision: <a href="https://reviews.freebsd.org/D55576" rel="noreferrer" target="_blank">https://reviews.freebsd.org/D55576</a><br>; >>> ---<br> >>> sys/conf/<a href="http://kern.opts.mk" rel="noreferrer" target="_blank">kern.opts.mk</a> | 5 +++++<br> >>> sys/conf/<a href="http://kmod.mk" rel="noreferrer" target="_blank">kmod.mk</a> | 8 ++++++--<br> >>> sys/modules/Makefile | 16 ++++++++++------<br> >>> 3 files changed, 21 insertions(+), 8 deletions(-)<br> >><br> >> There is a hige load of further devices which depend on USB which are not<br> >> part of the current set excluded; I assume they will now break with<br> >> dependency<br> >> issues if USB is no longer built but these modules are built.<br> >><br> >> Is there any plan to also "hide" all the other modules?<br> >><br> ><br> > As I said in my review, I'm generally uneasy about this trend...<br> <br> I never got that far as the review diff I looked at was broken at that point.<br> <br> This may also be wrong:<br> <br> % ls -l tools/build/options/*USB*<br> -rw-r--r-- 1 bz bz 49 Mar 21 2025 tools/build/options/WITHOUT_USB<br> -rw-r--r-- 1 bz bz 40 Mar 21 2025 tools/build/options/WITHOUT_USB_GADGET_EXAMPLES<br> -rw-r--r-- 1 bz bz 33 Mar 21 2025 tools/build/options/WITH_USB_GADGET_EXAMPLES<br> % cat tools/build/options/WITHOUT_USB<br> Do not build USB-related programs and libraries.<br> <br> <br> Usually we used to have a FOO_SUPPORT which would then also not build kernel<br> modules or not build FOO suport into (programs, libraries, and) kernel modules,<br> e.g. INET, INET6, NETGRAPH.<br> <br> Though, unless INET and INET6 started to become loadable seems wrong these days<br> and I'd use a check based on the kernel config (which I believe came years later<br> as an option) and remove the entire MK_INET[6]_SUPPORT checks for the kernel.<br> <br> The NETGRAPH example is a bad one as it seems to be unimplemeted for the kernel<br> side so NETGRAPH_SUPPORT description is misleading.<br> <br> <br> USB tends to be more tricky as it is fully loadable but then then answer<br> for people who don't want a system supporting USB would mean removing<br> all the modules (which we cannot do based on the kernel config).<br> <br> The question then remains whether a src.conf based knob is the right<br> thing and which one it should be. MK_USB seems wrong but more knobs do<br> not make it better as we have too many of them these days if you ask me.<br> <br> The answer may simply be to rm the modules if a system does not want/need<br> them. I kind-of see that as a rare special-case problem and if someone<br> really needs to ship a system like that then they may have to go the<br> extra length and maintain that bit?<br> <br> If we were really to support this in the build system then we should make<br> sure that all USB modules are no longer build.<br> <br> <br> Given I had my fingers in the USB modules list (though not the full one)<br> recently "uneasy" is maybe not enough for the feeling in my stomach.<br></blockquote><div><br></div><div>Given all this, maybe we should revert this change and move the discussion</div><div>to arch@. The USB vs USB_SUPPORT nails a lot of my uneasiness here.</div><div><br></div><div>Warner </div></div></div>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfojNLV5x_otOujYzvHYGx1Ge5Ywzq8BfQDaUEwWxt5sig>