From nobody Sun Feb 02 20:14:03 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 4YmLSM4Mt5z5msq3 for ; Sun, 02 Feb 2025 20:14:11 +0000 (UTC) (envelope-from sgharms@stevengharms.com) Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YmLSM0pqhz3TkQ for ; Sun, 02 Feb 2025 20:14:11 +0000 (UTC) (envelope-from sgharms@stevengharms.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stevengharms.com; s=protonmail; t=1738527247; x=1738786447; bh=0JxC4mIjJURzOAq+73RMMEV0wMnoU+PZQqMJ25L2JY4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=Q/ngI8ucWlUbd+vKYZeriIGGI/HhJXP3xd7P7AefIvWln6bUecBMocgBIUxpBd/tO vubpijbIKCoRhZYirMylAIJT6oktwEf1824Jif5J1Mc/gbknQVzsgGbGrNRRzdLkNM lBpSAU1ls1aR9RTZ92YeXWvF4eXcCorl7CABsLWE= Date: Sun, 02 Feb 2025 20:14:03 +0000 To: Tomek CEDRO From: "Steven Harms (High-Security Mail)" Cc: "freebsd-current@freebsd.org" Subject: Re: Adjustments to userland for a quieter startup (RC system) Message-ID: <44Sc-RwC_I83PwTD-UykFfG8EFcHnBwZscSteeNEqJ_sdnmc-wrhdj-kWf2XxYDln0qB70HW3AD9qqBLEkBNeohWxlugR68PuDNYVR85PBE=@stevengharms.com> In-Reply-To: References: Feedback-ID: 16996530:user:proton X-Pm-Message-ID: a4fe3b31aa72a75c15025c193a34e86a7f496345 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4YmLSM0pqhz3TkQ X-Spamd-Bar: ---- 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:62371, ipnet:185.70.43.0/24, country:CH] On Sunday, February 2nd, 2025 at 2:38 PM, Tomek CEDRO wr= ote: > One "black box" scenario that came to my mind we did not mention is > some embedded system that we really do not want to show anything OS > related just the final login prompt.. or was that the initial idea? That wasn't one of my main drivers, but once you settle that position at one extreme (silence) versus say a class on learning kernel design (maximal verbosity using FreeBSD as platform), it suggests that an RC mechanism that supports the full range of verbosity is useful. > Log levels is just an idea for generic commonly practiced solution > that may be applied to rc/init, you replace echo / printf with > log(lvl, fmsg, ..), but its quite a big task and not sure if really > critical right now / worth the time..? Is it critical? Probably not. Supporting more video hardware and wifi cards= is critical. But is it more than just mere chrome polishing? I think so. It's the first chance to show the market what the FreeBSD way looks like; it's a chance to show that it's not _entirely_ spartan. There's some consideration to tas= te and design. While Apple represents an extreme case, how the box feels when = it's opened is a legitimate concern. How the laptop looks at boot, I think, is a similar concern. > > Sadly boot_mute=3D"YES" was insufficient as well. It only seems to mute= /kernel/-level diagnostics. Afterward, my screen was still full of RC-orig= inating content. And yes, suppose we /could/ do an overlay until the login = prompt -- I think that should be supported. It's what I expected boot_mute= =3DYES to do by default, frankly. >=20 >=20 > Looks like the boot logo screen component needs an update, so it > covers the rc scripts too, and maybe show some animated spinner > indicating working stuff in the background, and this should fix the > problem right? Most systems work that way already, and pressing Tab or > Esc jumps to the log messages easily when necessary / possible / > allowed. I support this implementation. boot_mute=3DYES hides all diagnostic data up to the prompt being ready (surely one could hook getty's code for an ioctl?). I also think that ESC as a means for getting to the full diagnostics as in status quo is a great place to debug uh-oh moments. It's beyond my capability to size this story, *but* I can't imagine it being a weeks-long effort. Steven