Date: Wed, 08 Jun 2011 01:33:48 +0000 From: "Dieter BSD" <dieterbsd@engineer.com> To: hackers@freebsd.org Subject: Re: Testing a change to printf(9) Message-ID: <20110608013350.111860@gmx.com>
next in thread | raw e-mail | index | archive | help
>> 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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110608013350.111860>