From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 8 07:51:57 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15FF9106566C; Wed, 8 Jun 2011 07:51:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id C47DC8FC13; Wed, 8 Jun 2011 07:51:56 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1QUDAb-000CpB-OD; Wed, 08 Jun 2011 10:27:18 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Julian Elischer In-reply-to: <4DEED5B2.5050802@freebsd.org> References: <20110608013350.111860@gmx.com> <4DEED5B2.5050802@freebsd.org> Comments: In-reply-to Julian Elischer message dated "Tue, 07 Jun 2011 18:51:46 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Jun 2011 10:27:17 +0300 From: Daniel Braniss Message-ID: Cc: hackers@freebsd.org, Dieter BSD Subject: Re: Testing a change to printf(9) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 07:51:57 -0000 > 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" >