Testing a change to printf(9)

[Dieter BSD]

>> I've been working on fixing problems with printf(9), log(9) and
>> related functions. Today I tried converting printf(9) to write
>> to the log rather than directly to the console, unless the log is
>> not open, in which case the message is also sent to the console.
>> Printf(...) is now the same as log(LOG_INFO, ...).
> oh please no!
>
> from my perspective, I want my printf output to go to the console.
> immediately, regardless of where it goes after that.
> I don't care if there is or is not a log.
> I do NOT want to EVER have the problem I've had on linux where
> the last vital bit of output never made it out before the system stopped.
>
> once it's been shown on the console I don't care what happens to it..

Printfs to the console cause data loss. Easily repeatable.
Absolutely unacceptable.

You are welcome to fix the actual underlying problem. I would
love to see the underlying problem fixed! I've asked a few times
before, but I'll ask again. Why does a driver for one piece of
hardware have to block interrupts for all hardware? I thought
changing from spl to mutex was supposed to fix this?

My changes do not prevent a sysadmin from having printf output
go to the console, it gives them a choice. Currently there is
no choice.

>> I commented out the line in /etc/syslog.conf that sends
>> some log messages to the console. In multiuser mode,
>> normal printfs go to log, but not the console, as expected.
>>
>> Bootup messages, shutdown messages, and panic messages all
>> show up on the console as expected.
>>
>> Are there any other special cases to test?