From nobody Sat Mar 22 15:51:29 2025 X-Original-To: freebsd-current@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 4ZKkMM25zDz5qfDt for ; Sat, 22 Mar 2025 15:51:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 4ZKkML3f5jz3mYf for ; Sat, 22 Mar 2025 15:51:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-22438c356c8so58715245ad.1 for ; Sat, 22 Mar 2025 08:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1742658700; x=1743263500; 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=/b0qIJy5QCUudbUbVMmxHdG4jGEJ/XYjXbFqH4vIVFc=; b=gmDV09jx+SJ88C3RvcAvCnT/IQI26T4VlpbhBd4njN/CfWsbfad3g4HK6gaDGSYVze lcX6STml8Ko6fSzhbD1yWzr7fWz0s03mdwM0TikfRwaPH6jW2Y4neMfrZeIv6LLSnf4A 3tChNep9uRI6TG3zEXXjBIAl42TLc4eGBfoAkk8i27xDqEaErJdw1gZ5l0NvGLEUHSf0 008DCs9d9+aCfRXkeJF2EgC7aP8Lhep4prfD5j+0Vt/IrIhmdQsjbb3+1rHbPsFgrEv9 uZG5SHaXdEAg1TH2wB+ja+b53YZg/6xy13u0lWgxOTJXVsQhTl0K1hDNilPaCiewQuAr /FNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742658700; x=1743263500; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/b0qIJy5QCUudbUbVMmxHdG4jGEJ/XYjXbFqH4vIVFc=; b=XyimqApRSDB1WWSRXMM+zkwN5SX5dLV5eHao1ogcCR5qWqupdZz9bU9S0vWcm/I51U WN852j6f1SNr9fW8BftE1izWfdqHN5Q1mWT8CgdeIHfCLnZUb1z+fVuN+f6+YOqKxy0+ OhPC8tfTdfyUm1395gLZfW/ULQDpIbL98DNLHA+eQSPx6aZNNY/oq1RABgNqc1Z69i50 AvO8c48wFTgiQk72WR4zsvPnj6LIMcwVjB5AXk4qgwV9NU9yCacSPVURr9pfLnRBKDO7 NOgSD7hdo4OA/fpYx78w+YT9KBl8gn7tIVj914Rp5KQWhCNJ5RJFDShVCZsTTZQQVNuW fd6A== X-Gm-Message-State: AOJu0YxPv3jeFNzhKUIN77RQJmDsmeKO3k8IKpFGs+4tC2lDk6D/SYph fqIe/ZJdsFrZvwEFY18/NKXB7l1QLaijsfU93UlVGLFT+UcA3cuuWa8oVlhStznwc28smAszIuP Tp2Yxlq0zArprYNrHpR9quQZrAhwtP6eF7zahNA== X-Gm-Gg: ASbGnct02f/1dGFtDl3RDmFQgSovfkEHvT3WHgmCNf+7uTuquobW8BJK2MG31Qg09PB j2sNViQBMCNmUvy7/2nuOrQugBDxfC8mV+C7mKIpQYqO0tV97e3/lvk1Bg+5IrJzDLdMvznd9BV piz+x0FxuR/LgJc66D36CBiN2KuA== X-Google-Smtp-Source: AGHT+IFNpvNn6jOevyqyn6sdK+H1SpUVibZ4KhK7QcRsCAoVJDqIV9sJDjd7mms+1zFHLZ2yaaY6IWXDs4x2BB+l/WI= X-Received: by 2002:a17:902:f683:b0:226:30f6:1639 with SMTP id d9443c01a7336-22780e35e43mr103249435ad.51.1742658700163; Sat, 22 Mar 2025 08:51:40 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sat, 22 Mar 2025 09:51:29 -0600 X-Gm-Features: AQ5f1JqALGLt8hCix68F_PzF0Ocmy6xktNzm_aB30NJCiCMVbBboqB2kH1T5Ct4 Message-ID: Subject: Re: Confused by boot_mute documentation, terminal systems, and goals To: "Steven Harms (High-Security Mail)" Cc: "freebsd-current@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000c9d6d30630f058f6" 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: 4ZKkML3f5jz3mYf X-Spamd-Bar: ---- --000000000000c9d6d30630f058f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 21, 2025 at 4:13=E2=80=AFPM Steven Harms (High-Security Mail) < sgharms@stevengharms.com> wrote: > Folks, > > I am attempting to figure out what boot_mute wants me to do. > It turns off output to the console. You probably don't want this option. Or at least, in the past this option was for something else. > I'm trying to make a "laptop guide" and I'm confused. I'm not a C > programmer at this scale of sophistication so there's a decent chance I'm > foolishly making an error, but current is not doing what I expect. > > > 1. boot_mute doesn't appear in [loader.conf(8)][1] > > We should add it to the man page. Especially since its meaning has changed through time from a niche option that we specifically didn't document to one that's in use. Originally, it was designed for router companies and similar that have lots of output on boot that what to have a console in case of panics. But it was repurposed when in 2013 vt was merged and it wasn't noticed due to the size of the code coming in. Originally, it was done by Whistle in 1993 for muting the console on their WhistleJet internet systems since it printed things Whistle generally didn't want disclosed. So this was intentional, but lead to a bad outcome since the vt(4) authors weren't aware of this when vt was merged, and none of the reviewer caught it. > > 1. In the defaults/loader.conf file it [appears][2] and says: that it > exists to mute the console. I daresay that it's doing more than that, > because activating it puts a logo + beastie orb on the screen. Questio= n: > Should the comment be updated? > > Not quite. The logo + beastie orb is the preferred way for graphics consoles to have graphics all the way from the boot loader until X11 starts= . > > 1. The only other mention of boot_mute is on the line that specifies > that the overlay image can be controlled through configuration of the > [splash] value implying that instead of using the encoded array of > unsigned char in the kernel at > https://github.com/freebsd/freebsd-src/blob/main/sys/dev/vt/logo/logo_= beastie.c. Whoa! > A nice configurable option? Nice. Looking at the git history on that f= ile > it appears to be part of splash(4). And /that/ document says ..."work = with syscons(4) > only". OK so maybe that comment in defaults also needs updating? Becau= se... > > I'm surprised by this, actually. We pass the splash screen into the kernel from the boot loader. splash(4) is a different thing than this, however, and does only work with syscons which is actively being removed from the kernel. Prior to vt(4) coming into the system, you wouldn't set boot_mute, but one of the splash variables and it would just stay in place from the boot loader all the way through. Finding this in vt/logo surprises me. It looks like this has changed, which is unfortunate. boot_mute originally meant something else. Since this was botched in 2013 with the vt merge, though, I don't see how we put it back to its original meaning. Though, honestly, having a kenv to control this would be better and we could phase out the boot_mute entanglement. It is documented, kinda, in splash(4), as two lines at the end of a huge amount of text that's not relevant anymore unless you use syscons. So it's there, but buried. The man page needs to be completely revamped. The other caveat: if you booted in 'text' mode (which you are unlikely to do on a laptop, but would if you enable a dual console with serial you are), then we don't load it. > > 1. My impression is that vt(4) is the way forward at present which > means that I was following a bad path and we're /back/ to using the > [in-kernel defined image][3] for the splash screen that's triggered by > boot_mute? I really don't understand the image packing as chars well e= nough > to reverse how to create a BMP from an array of hex values, but, eh...= is > this the one that's being shown? Seems like it. There's also quite a > bit of logic inside of sys/dev/vt/vt_cpulogos.c[3] that suggests that = it's > trying to use arrays of chars as overlay. > > Yea, compiling into the kernel is discouraged. It was originally a niche thing and now that the boot loader can handle it, that's best ignored. > OK, so AFAICT, there are two terminal rendering systems, > under-/mis-documented loader.conf flags, and two places where images are > defined: in the vt device directory and the images/ directory. Question: > Can anyone confirm / deny my assessment? > It's a mess. There's how it kinda works, and then how it should work and the dearth of documentation exacerbates this (but when boot mute came in and then later when vt bogusly(IMHO) repurposed this). > After all that I'm still a bit confused as to what the expected/desired > behavior is. Can anyone help me figure out what the desired behavior is > (and maybe I can update the comments)? My current plan is to turn the arr= ay > into 0x00 and see what happens, but I'd like to know how I can turn the > results of that experiment into a patch. > Short term, your best bet is to use boot_mute=3DYES and change splash in loader.conf to get the image you want. Longer term we need to fix this to decouple the two, though we likely need to have a release or two where they both do things (and possibly fix bugs in vt(4) when a splash screen is present that lead it to outputting text). But that's a bigger discussion in the community and it's possible others don't share my vision for a path forward. Warner > Best, > > Steven > > [1]: > https://github.com/freebsd/freebsd-src/blob/main/stand/defaults/loader.co= nf.5 > [2]: > https://github.com/freebsd/freebsd-src/blob/283be95ea29abd7f867e4084bafe3= 68c47f6c038/stand/defaults/loader.conf#L134 > [splash]: > https://github.com/freebsd/freebsd-src/blob/283be95ea29abd7f867e4084bafe3= 68c47f6c038/stand/defaults/loader.conf#L30 > [3]: > https://github.com/freebsd/freebsd-src/blob/main/sys/dev/vt/vt_cpulogos.c= #L79-L91 > --- > > Public Key: 22BE39E2FA68D8BA8DC4B43A55A16D8CE2B036DE > > Messages from this account are considered the best-secured and most > reliable. Send information regarding health, wealth, or requiring higher > standards of security to this address. > > Sent with Proton Mail secure email. > --000000000000c9d6d30630f058f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Mar 21,= 2025 at 4:13=E2=80=AFPM Steven Harms (High-Security Mail) <sgharms@stevengharms.com> wrote:
=
Folks,

I am attempting to figure out what boot_mute = wants me to do.

It turns off output t= o the console. You probably don't want this option. Or at least, in the= past this option was for something else.
=C2=A0
I'm trying to make a "laptop guide" an= d I'm confused. I'm not a C programmer at this scale of sophisticat= ion so there's a decent chance I'm foolishly making an error, but c= urrent is not doing what I expect.

  1. boot_mute doesn't appear in [loader.con= f(8)][1]

We should a= dd it to the man page. Especially since its meaning has changed through tim= e from a niche option that we=C2=A0specifically didn't document to one = that's in use. Originally, it was designed for router companies and sim= ilar that have lots of output on boot that what=C2=A0to have a console in c= ase of panics. But it was repurposed when in 2013 vt was merged and it wasn= 't noticed due to the size of the code coming in. Originally, it was do= ne by Whistle in 1993 for muting the console on their WhistleJet internet s= ystems since it printed things Whistle generally didn't want disclosed.=

So this was intentional, but lead to a bad outcom= e since the vt(4) authors weren't aware of this when vt was merged, and= none of the reviewer caught it.
=C2=A0
  1. In the defaults/loader.conf file it [appears][2] and says: that = it exists to mute the console. I daresay that it's doing more than that= , because activating it puts a logo + beastie orb on the screen. Question: = Should the comment be updated?

=
Not quite. The logo=C2=A0+ beastie orb is the preferred way for = graphics consoles to have graphics all the way from the boot loader until X= 11 starts.
=C2=A0
  1. The only ot= her mention of boot_mute is on the line that specifies that the overlay ima= ge can be controlled through configuration of the [splash] value implying t= hat=C2=A0instead of using the enc= oded array of unsigned char in the kernel at=C2=A0https://github.com/freebsd/freebsd-src/blob/main/sys/dev/vt/l= ogo/logo_beastie.c.=C2=A0Whoa! A nice configurable option? Nice. Lookin= g at the git history on that file it appears to be part of splash(4). And /= that/ document says ..."work with=C2=A0syscons(4) only". OK so maybe that comment in defaults also= needs updating? Because...

I'm surprised by this, actually. We pass the splash screen into= the kernel from the boot loader. splash(4) is a different thing than this,= however, and does only work with syscons which is actively being removed f= rom the kernel.

Prior to vt(4) coming into the sys= tem, you wouldn't set boot_mute, but one of the splash variables and it= would just stay in place from the boot loader all the way through. Finding= this in vt/logo surprises me. It looks like this has changed, which is unf= ortunate. boot_mute originally meant something else. Since this was botched= in 2013 with the vt merge, though, I don't see how we put it back to i= ts original meaning.

Though, honestly, having a ke= nv to control this would be better and we could phase out the boot_mute ent= anglement.

It is documented, kinda, in splash(4), = as two lines at the end of a huge amount of text that's not relevant an= ymore unless you use syscons. So it's there, but buried. The man page n= eeds to be completely revamped.

The other caveat: = if you booted in 'text' mode (which you are unlikely to do on a lap= top, but would if you enable a dual console with serial you are), then we d= on't load it.
=C2=A0
  1. My impre= ssion is that vt(4) is the way forward at present which means that I was fo= llowing a bad path and we're /back/ to using the [in-kernel defined ima= ge][3] for the splash screen that's triggered by boot_mute? I really do= n't understand the image packing as chars well enough to reverse how to= create a BMP from an array of hex values, but, eh...is this the one that&#= 39;s being shown? Seems like it.=C2=A0There's also quite a bit of logic inside of=C2=A0sys/dev/vt/vt_= cpulogos.c[3] that suggests that it's trying to use arrays of chars as = overlay.

Yea, compil= ing into the kernel is discouraged. It was originally a niche thing and now= that the boot loader can handle it, that's best ignored.
=C2= =A0
OK, so AFAICT, th= ere are two terminal rendering systems, under-/mis-documented loader.conf f= lags, and two places where images are defined: in the vt device directory a= nd the images/ directory. Question: Can anyone confirm / deny my assessment= ?

It's a mess. There= 's how it kinda works, and then how it should work and the dearth of do= cumentation exacerbates this (but when boot mute came in and then later whe= n vt bogusly(IMHO) repurposed this).
=C2=A0
After all that I'm still a bit confused as t= o what the expected/desired behavior is. Can anyone help me figure out what= the desired behavior is (and maybe I can update the comments)? My current = plan is to turn the array into 0x00 and see what happens, but I'd like = to know how I can turn the results of that experiment into a patch.<= /div>

Short term, your best bet is to use boot_mute=3DYES and chang= e splash in loader.conf to get the image you want.=C2=A0 Longer term we nee= d to fix this to decouple the two, though we likely need to have a release = or two where they both do things (and possibly fix bugs in vt(4) when a spl= ash screen is present that lead it to outputting text).=C2=A0 But that'= s a bigger discussion in the community and it's possible others don'= ;t share my vision for a path forward.

Warner
=C2=A0
Best,

Steven
<= div style=3D"font-family:Arial,sans-serif;font-size:14px">
---


Messages from this account are considered the best-secured and most reliab= le. Send information regarding health, wealth, or requiring higher standard= s of security to this address.

Sent with Proton Mail secure email.
--000000000000c9d6d30630f058f6--