[Bug 230757] [syscons] random wrong color for kernel messages

[Bruce Evans]

On Mon, 10 Sep 2018, Koro wrote:

>> In FreeBSD-11:
>> - for boot messages, configure SC_KERNEL_CONS_ATTR to anything except its
>>     default of FG_WHITE (0xf).
>> - after booting, use the hw.syscons.kattr sysctl to change the array of
>>     MAXCPU kernel attributes to whatever you want (all FG_WHITE to get the
>>     old behaviour).  sysctl(8) doesn't handle arrays very well, so it takes
>>     rarely-used options to even print the values in the array.
>
> I tried doing this real quick, but it did not change a thing:
> ...
>        memset(kattr, 0x0f, 256);
>
>        if (sysctlbyname("hw.syscons.kattr", NULL, 0, kattr, 256) == -1)
>        {
>            perror("sysctl");
>            return 1;
>        }
> ...
>
> It doesn't error out, but it does not change a thing, I still kept getting 
> colored messages. Maybe I misunderstood your instructions? This is on 
> 11.2-RELEASE by the way.

Sorry, my instructions were bad.

The sysctl works to affect the static attribute table, but for normal
kernel output that is only used at boot time (to initialize the higher
level per-CPU terminal state).  The sysctl does work to affect the
attributes used by emergency output when normal output would deadlock.

The following hack almost works:

 	options 	SC_KERNEL_CONS_ATTR=(0x100|FG_WHITE)

This works for keeping the old default of FG_WHITE by truncating away the
0x100 in the attribute table, while keeping it in the ifdef which decides
if the default is being used.  Unfortunately, the compiler is too smart,
so it warns about the truncation.  syscons.o must be compiled with 'WERROR='
to kill -Werror so that the warning is not turned into an error.

I tested this by adding -WERROR= manually.  This can be automated, but it
is much easier to edit the attribute table in syscons.c than to edit files.*
to add a special rule for making syscons.o.

>> But don't turn it off.  Try using better colors (don't use dark gray).
>> Even I like colorized kernel messages, and I stopped using colorized ls
>> 25 years ago.
>
> It's not so bad with only dark gray (though it looks a bit broken), but once 
> you add more CPUs, it starts looking like an xmas tree. I too, like my 
> consoles to be gray and boring and disable colored ls.

Do you also make the kernel output gray instead of bright white so that it
is indistinguishable from higher level console output? :-)

> And also, unless one actively works on the kernel, I fail to see the need to 
> know from which CPU did a specific kernel message originate.

The colors are indeed most useful for kernel development.  But most kernel
output should be for errors, so there shouldn't be much of it except during
kernel development.  And if there is a lot, then it might be interleaved.
The colors are very useful for decoding interleaved output.  Using
PRINTF_BUFR_SIZE limits interleaving but only works at the level of
individual printfs.

If you don't want to mess with WERROR, the only workaround seems to be to
use a real non-default SC_KERNEL_CONS_ATTR.  I would use FG_YELLOW.  The
pcvt driver (which was in at least FreeBSD[2-5] and which was also named vt)
used red or light red for kernel output.  Red is a good color for errors that
should never occur, but I never tried it for syscons.

Colored backgrounds don't work so well.  Syscons (EGA) yellow on blue is not
too bad.  I like blue on yellow, but not with EGA colors (there is no EGA
background yellow, only brown).  I tried using yellow on blue for instead of
the low-contrast dark gray on black for colorized kernel messages, but that
was too bright.  It shows some problems with coloring when scrolling and/or
clearing to the end of a line propagates the kernel background too far.

Bruce