From nobody Sun Feb 02 10:19:11 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 4Ym5Fz2TBxz5mFdq for ; Sun, 02 Feb 2025 10:19:19 +0000 (UTC) (envelope-from sgharms@stevengharms.com) Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136]) (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 4Ym5Fz0K8Yz3S91 for ; Sun, 02 Feb 2025 10:19:19 +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=1738491555; x=1738750755; bh=LvvmW92WagU1WjMJcr5h1JZdt8RkohEC3NAcyb11jAg=; 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=iOdxDLhBNW1is8lgZDzMn8qfqbg5D0bxc8CMxkhK476WKgFOTuLtu1g6rVkVtQ8dV SAWblilYmdm8mDNIvPKdcPZEt3ke8UzKvklq55BBrkIvKYh3XH6IHSRiI8O9xT5YH1 KljWyK9fZMkH9PCgV2KjEPZz+ZEHRrpRqemnPCDs= Date: Sun, 02 Feb 2025 10:19:11 +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: In-Reply-To: References: Feedback-ID: 16996530:user:proton X-Pm-Message-ID: 373a0bd3e9024a418dd71d3bbb857810827df4b6 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: 4Ym5Fz0K8Yz3S91 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.40.0/24, country:CH] > Okay, I am sorry, I mixed the general idea with detailed PR that aims > just updating routing and devmatch parts with user selectable option > not changing a defaults, thus my previous remarks are invalid and > updated, I apologize! :-) A goal of this PR was to flush out dialogue around whether there was a univ= ersal noise level-adjusting knob in the RC system. [jlduran]'s more ambitio= us PR, my PR, and the discussion to this post suggest "no." I think it's pr= obably right to generalize the discussion! I also realize that this is a probably a controversial perspective. My moti= vation here is ultimately service to the FreeBSD Laptop project. Windows an= d OSX have conditioned many in the population of the FreeBSD-curious to exp= ect a lot less text on startup if things are going well.=20 To those who say "Yes, seeing the diagnostic data is why FreeBSD is so grea= t," I say: In a server/device context, I'd not change anything (something m= y PR may have flubbed in its implementation). ***But***, I contend that for= FreeBSD to thrive on a wider population of laptops and access a wider popu= lation of users, some options (including such a noise knob for the RC syste= m) ought be available. The extent that [helloSystem] went to hide messages = suggests an unmet need.=20 [helloSystem]: https://hellosystem.github.io/docs/developer/boot.html#boot-= mute [jlduran]: https://github.com/jlduran/freebsd-src/pull/90/files > * There is already `rc_info` that may be used? > https://github.com/freebsd/freebsd-src/blob/50c962d773705f60d32c29f8e4bb2= 743ab55733b/libexec/rc/rc.conf#L29 I could see that and/or rc_debug replacing RC scripts' use of `echo`, thoug= h. But (per "it's controversial"), we'd need future RC authors to adopt a n= otion of "log level output" versus "printf/echo to the screen." My PR was m= odest in its aims and didn't want to edit all the `echo`s. [jlduran] *did* = dare more bravely :) Although it seems (from the comments) that rc_debug ha= s some complex interactions with rc.subr that might make this option (my fa= vorite thus far) more complex than expected. [rc.subr]: https://github.com/freebsd/freebsd-src/blob/50c962d773705f60d32c= 29f8e4bb2743ab55733b/libexec/rc/rc.conf#L26 =20 > * There is already `rc_startmsg` that may be used? > https://github.com/freebsd/freebsd-src/blob/50c962d773705f60d32c29f8e4bb2= 743ab55733b/libexec/rc/rc.conf#L30 This was insufficient. It only squelched the "Starting ${name}" line :-/. e= .g. all the data e.g. about setting up a default route / interface output w= ere still logged. =20 > * If really necessary `_msgs` can be replaced with `_verbose` suffix? > https://github.com/freebsd/freebsd-src/blob/50c962d773705f60d32c29f8e4bb2= 743ab55733b/libexec/rc/rc.conf#L568 Seems promising, but this would mean more conditional logic per each flag? = I think that's probably insufficiently general. `info` with its control in = `rc_info` per your earlier suggestion would seem the way to go. > * I guess the idea is to silence the terminal? How many flags need to > be put to silent instead just one? Why not just put a boot logo image > if you really do not want to see the boot messages? It may provide > expected user experience and will not impact diagnostic information > that are usually useful :-) Sadly boot_mute=3D"YES" was insufficient as well. It only seems to mute /k= ernel/-level diagnostics. Afterward, my screen was still full of RC-origina= ting content. And yes, suppose we /could/ do an overlay until the login pro= mpt -- I think that should be supported. It's what I _expected_ boot_mute= =3DYES to do by default, frankly. Perhaps the take-away should be: * Existing interfaces are insufficient to let people easily tune their leve= l of RC output * Resolve: Is this something that should be available? * If so: resolve via log level, per-function verbosity suffixes, provide = a longer overlay bitmap duration option, or some other means Thank you for your consideration, Steven Steven