Date: Tue, 07 Jun 2011 18:51:46 -0700 From: Julian Elischer <julian@freebsd.org> To: Dieter BSD <dieterbsd@engineer.com> Cc: hackers@freebsd.org Subject: Re: Testing a change to printf(9) Message-ID: <4DEED5B2.5050802@freebsd.org> In-Reply-To: <20110608013350.111860@gmx.com> References: <20110608013350.111860@gmx.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DEED5B2.5050802>