Date: Wed, 08 Jun 2011 10:27:17 +0300 From: Daniel Braniss <danny@cs.huji.ac.il> To: Julian Elischer <julian@freebsd.org> Cc: hackers@freebsd.org, Dieter BSD <dieterbsd@engineer.com> Subject: Re: Testing a change to printf(9) Message-ID: <E1QUDAb-000CpB-OD@kabab.cs.huji.ac.il> In-Reply-To: <4DEED5B2.5050802@freebsd.org> References: <20110608013350.111860@gmx.com> <4DEED5B2.5050802@freebsd.org>
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. I agree 100%! file system full ... > 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" > > > > > > _______________________________________________ > 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?E1QUDAb-000CpB-OD>