From nobody Tue Mar 3 19:47:16 2026 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4fQRCk2f24z6TXlg for ; Tue, 03 Mar 2026 19:47:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4fQRCj6j5Qz3cfv for ; Tue, 03 Mar 2026 19:47:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-358d80f60ccso2761974a91.3 for ; Tue, 03 Mar 2026 11:47:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1772567247; cv=none; d=google.com; s=arc-20240605; b=cSjwGXYPVaLRsnKfmCUD9xqZmAiPu6rUQIR2nxAeBoPPyn31qj6C86z85+kpB7s5ji qMfJsCPBir+mEuI3vn82E8Q+7YiQt75AvnD7vY4cClgBiLAwdheDD+I6q46OKJJD+p4T CmNbt0RomviQpmkshXePg+XASHtHV/aKmbCx5SZnibtT/Ve6Dz3BACo83mYq/znCT1Yf Z/FIKWAt9pH5/67dUqj0r+D2VUFufYbLD3+mmgjUIbmk7bjl96NVi7RL51r2zc0YZDn0 Wb0FFPIt/Sr9updSD4CCSVxtzkqPTZbBy9SPkOfRQ+U/1zMXl7ahNfVPJ/9DUJ3yw/ZB ZZrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=e82ujAwuZLVXawVXxQHQjNxiqL+TXMIyJ+3YKj6n/Gg=; fh=MNXipXUQ83Uw4F+RpnfLqHzq/29+GFdibcTvIvgWwdQ=; b=cwu18FRMdQwkGJRaJOSRTWQcqYbOuwrGGRmp53rzqrIeSNeKn6Iar4Z9qNwT82wR6y 6Sb37UdeGX50XoSdk1c3GE6TdYp3yiBRHAODsrKSO4dYH2brfX7q5I+acgQfnW6qRtso mP+30ZJCcoKTL+glg1iUBA7saSiW0gmc51vV2XcFddJBIE/OorL+g58OJjffnAg632Oc Eu63y6cNKYeBaePvzCnKIX+p/5nUnQK6IeS8g4uYiekNf24K7zYehc9jDVXNZ9pSoHWU uLhyPbZfQm3cGtp8q/r4W2h20h3BjzEGE9ihZSGl4yBg1j4BTRbJS1rX/1KrrC+YH/A1 DlwQ==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1772567247; x=1773172047; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=e82ujAwuZLVXawVXxQHQjNxiqL+TXMIyJ+3YKj6n/Gg=; b=yRW0uyWcsk6cxZos9l/ormUVMQSz01dyfQ7dvb2i1QzmGqTKM6GLUTl5H1IsTZcjZ3 S3JZV7titpldoufMcGBqU25zH37a5qdQlcBdmvPMDYmOAzY/aVxh3aZI/YuzcIMspDGF CMEwvBRan1bC+oxqePPT4jknWN4VqHRZe2gDqChZTclWpfF3ykkg3ID66qnOxakBJLmY gBwG/tyi0PIthkE6vv8p1hA5wIEoDxpJ/fFWMgizKghTjVgBrtFKg2DGXV0BM7mcXx/G VZF26VWrlY1zZsPSZp8fuSh13P8mQG4fQ0+11B0gOacS+PMGV8W5kkRgrwPRiwS42OFP zIMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772567247; x=1773172047; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=e82ujAwuZLVXawVXxQHQjNxiqL+TXMIyJ+3YKj6n/Gg=; b=h+8poY+Irv6Q5pwp9t9IsPkyikPG8pBwajBzcPBe7QE0k8fXKnifnuFLAgI1hZ9lTA HVehmq3uMSfmt0ORQf57oK2ZPR0wJ2ZZLkq30biJnK52CVaTe7iGvrMiH6lDW+qSPieQ crMYbl9O8sqwehA9hxC6HFJSbYjdaDK1A9c8oLWjzARU7LhlOKUuWMzAKXzKdzjdv08I FqF+TLbDTMTXUi2N9kAoh+A1J80jN4w7uR8mu4P4QZQdd0G66hVonroKuCdRXkBc6CL2 0K3CY+hDRWsix33hPm1qvCT0UxAsjusiXkEGpxzrrJ4uGBGw4Po7F3qMa9syIxvGEVpN emKQ== X-Forwarded-Encrypted: i=1; AJvYcCXXjg5HRTFTCLI+URwsf3khc0/yYpJYKWJs8btGg3As4+Yrq3fhB7qgh3ySHxE0p3IbfE6/q4ldLafQhN3xKKryiNpn7g==@freebsd.org X-Gm-Message-State: AOJu0YyxwWZpLxWn0TeHPZPUG7RDXWZu0Q1f0bV6VKJEpLm4hRCWPNZu r+G7s+WlixUE7V2my3P3AfTACNrYaOjth8TAcPMV/3diuSuWP5tTbXYSM6sDtUOcIhT15N/WmKl c5R7nsXFpBl9B5ysM62pASIeFw3oeNqM5KN03umAEzA== X-Gm-Gg: ATEYQzy+hc0sdrTl8hVy2HmDGyOVEC2kJdbU2SwFI+nLJZXyFgP/J5rq3ILOP4XxHVN RNhbooonFraa7a37LMvhYdHV0NwnsURkYJE+bn+c5LaXyqjDEmihtDDZrhmTGX8Z+prngO53Rhi V1uhc2IUYoB/+h2O/ck52NRzQi939qFRDaGvjc09k866BQF4WtD57KLhlCzAUWxnjsQVD9nyBgS aICkkhfetpj6f5vEwNMj+4B+Pu+4njZeDtvjYuMqLn3+mwagv/CUYBUsaNuiBsy7HOxUNHBu58j 61nW0hAjmON5sJUDDA== X-Received: by 2002:a17:90b:2ecd:b0:359:9b45:7754 with SMTP id 98e67ed59e1d1-3599b4587b7mr2906989a91.32.1772567247129; Tue, 03 Mar 2026 11:47:27 -0800 (PST) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 References: <69a668aa.3785e.4a16f236@gitrepo.freebsd.org> <1s9oq316-3q4o-9273-3qos-3n3o793ns725@mnoonqbm.arg> <947orn62-43rq-383n-son8-90o6q2275os6@serrofq.bet> In-Reply-To: <947orn62-43rq-383n-son8-90o6q2275os6@serrofq.bet> From: Warner Losh Date: Tue, 3 Mar 2026 12:47:16 -0700 X-Gm-Features: AaiRm53Zv_tKorRK-ITXGCK2iLNbhnoxjz7oT4KC0khoMQy3jRReZIYIIZx_ELo Message-ID: Subject: Re: git: c47cefba8312 - main - Only build USB-related modules if MK_USB != no To: "Bjoern A. Zeeb" Cc: Enji Cooper , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="0000000000001b1ce5064c23f90e" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4fQRCj6j5Qz3cfv X-Spamd-Bar: ---- --0000000000001b1ce5064c23f90e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 3, 2026 at 12:25=E2=80=AFPM Bjoern A. Zeeb wro= te: > On Tue, 3 Mar 2026, Warner Losh wrote: > > > On Tue, Mar 3, 2026 at 11:29=E2=80=AFAM Bjoern A. Zeeb = 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=3Dc47cefba831240a1b3de375f18134b9= 3cf998f5c > >>> > >>> commit c47cefba831240a1b3de375f18134b93cf998f5c > >>> Author: Enji Cooper > >>> AuthorDate: 2026-03-03 04:49:54 +0000 > >>> Commit: Enji Cooper > >>> CommitDate: 2026-03-03 04:50:03 +0000 > >>> > >>> Only build USB-related modules if MK_USB !=3D no > >>> > >>> This change moves the thunderbolt module and other USB modules > under a > >>> MK_USB !=3D 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 thes= e > days > and I'd use a check based on the kernel config (which I believe came year= s > 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 --0000000000001b1ce5064c23f90e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Mar 3, = 2026 at 12:25=E2=80=AFPM Bjoern A. Zeeb <bz@freebsd.org> wrote:
On Tue, 3 Mar 2026, Warner Losh wrote:

> On Tue, Mar 3, 2026 at 11:29=E2=80=AFAM 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://c= git.FreeBSD.org/src/commit/?id=3Dc47cefba831240a1b3de375f18134b93cf998f5c
>>>
>>> commit c47cefba831240a1b3de375f18134b93cf998f5c
>>> Author:=C2=A0 =C2=A0 =C2=A0Enji Cooper <ngie@FreeBSD.org>= ;
>>> AuthorDate: 2026-03-03 04:49:54 +0000
>>> Commit:=C2=A0 =C2=A0 =C2=A0Enji Cooper <ngie@FreeBSD.org>= ;
>>> CommitDate: 2026-03-03 04:50:03 +0000
>>>
>>>=C2=A0 =C2=A0 Only build USB-related modules if MK_USB !=3D no<= br> >>>
>>>=C2=A0 =C2=A0 This change moves the thunderbolt module and othe= r USB modules under a
>>>=C2=A0 =C2=A0 MK_USB !=3D no conditional to ensure that users n= ot desiring USB support
>>>=C2=A0 =C2=A0 can easily build systems without USB-specific dri= vers using this knob.
>>>
>>>=C2=A0 =C2=A0 MFC after:=C2=A0 =C2=A0 =C2=A0 1 week
>>>=C2=A0 =C2=A0 Reviewed By:=C2=A0 =C2=A0 imp
>>>=C2=A0 =C2=A0 Differential Revision: https://reviews.f= reebsd.org/D55576
>>> ---
>>> sys/conf/kern.opts.mk |=C2=A0 5 +++++
>>> sys/conf/kmod.mk=C2=A0 =C2=A0 =C2=A0 |=C2=A0 8 ++++++--
>>> sys/modules/Makefile=C2=A0 | 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;=C2=A0 I assume they will now bre= ak 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?<= br> >>
>
> 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 poin= t.

This may also be wrong:

% ls -l tools/build/options/*USB*
-rw-r--r--=C2=A0 1 bz bz 49 Mar 21=C2=A0 2025 tools/build/options/WITHOUT_U= SB
-rw-r--r--=C2=A0 1 bz bz 40 Mar 21=C2=A0 2025 tools/build/options/WITHOUT_U= SB_GADGET_EXAMPLES
-rw-r--r--=C2=A0 1 bz bz 33 Mar 21=C2=A0 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 kerne= l
modules or not build FOO suport into (programs, libraries, and) kernel modu= les,
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 ye= ars later
as an option) and remove the entire MK_INET[6]_SUPPORT checks for the kerne= l.

The NETGRAPH example is a bad one as it seems to be unimplemeted for the ke= rnel
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.=C2=A0 MK_USB seems wrong but more knobs d= o
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.=C2=A0 I kind-of see that as a rare special-case problem and if someon= e
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 stoma= ch.

Given all this, maybe we should rev= ert this change and move the discussion
to arch@. The USB vs USB_= SUPPORT nails a lot of my uneasiness here.

Warner= =C2=A0
--0000000000001b1ce5064c23f90e--