On 6/7/11 6:33 PM, Dieter BSD wrote:
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.
NO! a kernel printf goes to the console however it may be redirected.
It MAY also decide to go somewhere else.
But not if it means unreliable delivery to the serial port.
The console MUST get the output in a completely reliable manner unless
it's been disabled.
do not do anything that gets between the console and the problem.
if you want to send it on to some other secondary sevice such s a log,
then disable the console and take the priority service but do NOT do
any of the silly tricks that some people have tried in the past like
making the console just one of several things on a mux. all with equal
ability to screw up the other. I want the console to be the last
refuge in a dying system.
if a send a char there I KNOW it's gone out. it is synchronous and it
doesn't lie.
if you don't want a reliable console then turn it off but don't make
something else that is unreliable and call it the console.
call it anything else but don't screw up the console.
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?
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
