Re: highlighted (was: colored) kernel messages on serial console

"Greg A. Woods" <[email protected]> Sat, 01 Aug 2026 14:04:54 -0700
Newsgroups gmane.os.netbsd.devel.kernel
Organization Planix, Inc.
Message-ID <[email protected]>
--pgp-sign-Multipart_Sat_Aug__1_14:04:44_2026-1
Content-Type: text/plain; charset=US-ASCII

At Tue, 28 Jul 2026 17:16:01 -0400, Greg Troxel <[email protected]> wrote:
Subject: Re: Colored kernel messages on serial console
>
> I take it as
>   - We collectively do not want to add this feature to NetBSD.

I'm not so sure that's true.  It certainly doesn't apply to me!  Such a
feature, with appropriate controls and some options, could be highly
useful to those of us who do some significant work via serial consoles.

I.e. I think having kernel messages highlighted in some way is extremely
useful and it is sorely missed on serial consoles by someone like me who
uses both serial consoles and wscons consoles and has become very
accustomed to the highlighting done by wscons.

>   - Most of the concern was about color being problematic and logging of
>     serial console bytes being more troubled.

I think this discussion may have been side-tracked by the implication
from the demo patch that this had something to do with actual colour,
specifically the default "options WS_KERNEL_FG=WSCOL_GREEN" used by many
(nearly all!) standard kernel configurations for wscons.

Instead it might help if we focus on the fact that highlighting of some
sort is "standard" for kernel messages in wscons and colours are only
one way of highlighting.

I'd really like to see kernel messages displayed in bold text on my
VT100, DMD5620, and similar old monochrome serial terminals, for
example.  However I'd prefer green for emulators like xterm that I use
to connect to serial consoles.  :-)

I'm pretty sure VT100 highlighting is also more or less universal for
any terminal or emulator even approaching ANSI X3.64 compatability,
i.e. everything "ANSI" supports at least "CSI 1" (i.e. the SGR1
sequence) and "CSI 0".  SGR parameters above SGR8, especially those for
colours, are less portable.

>   - There were a few comments of "why don't we make it an option" and I
>     think that others may be worried that this will happen.  In general
>     it is not a reasonable response to accept anything as long as its
>     default off.

Very true, but this particular example is simply extending a well known
(and if I'm not mistaken, widely loved and "expected") feature of wscons
to serial consoles.  It's not just "any old thing".

> * As will not surprise you, I also used a DECwriter, but it wasn't mine
>   and I don't still have it!

Sadly my DECwriter III long ago succumbed to the deterioration of time
in poor storage conditions and was rendered to the recycler.

Note most printing terminals using hammers and ink, including dod-matrix
printers like the DECwriters, could use CR and reprinting of the same
line to effectively double-strike characters on a line giving an
impression of bold highlighting.

However none of the DECwriters I know of supported X3.64 SGR modes.
Even the DECwriter-IV (the first table-top one, capable of printing
graphics), which the user's guide claims to be X3.64-1979, X3.4-1977 and
X3.41-1977 compatible, didn't have the equivalent of a "bold" character
set so far as I can tell (though it does have a VT100 character set with
the line drawing characters).

The proposal for a sysctl allowing arbitrary prefix and postfix
character sequences for kernel messages could allow for BEL to be used
for printing terminals like the DECwriters (something one of my former
professors would likely be extremely hateful of -- I once put BEL in my
$PS1 on a very slow and overloaded old PDP-11 to get my attention when a
compile completed, and the distracting noise when I was doing
shorter-running commands made him rather mad at me).

--
					Greg A. Woods <[email protected]>

Kelowna, BC     +1 250 762-7675           RoboHack <[email protected]>
Planix, Inc. <[email protected]>     Avoncote Farms <[email protected]>

--pgp-sign-Multipart_Sat_Aug__1_14:04:44_2026-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP Digital Signature

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCam5fbwAKCRBmfXG3eL/0
f4RWAKCYh5XeSZ43etOMmGN1yRj3+RrkagCeMmf0/hf5QZjvlU9Ieei8B57BrG4=
=6OGA
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Sat_Aug__1_14:04:44_2026-1--