From owner-svn-src-head@FreeBSD.ORG Mon Feb 20 05:55:45 2012 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80D711065670; Mon, 20 Feb 2012 05:55:45 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id 0686C8FC13; Mon, 20 Feb 2012 05:55:44 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1K5texG024111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Feb 2012 16:55:42 +1100 Date: Mon, 20 Feb 2012 16:55:40 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Xin LI In-Reply-To: <201202200105.q1K15HRB024037@svn.freebsd.org> Message-ID: <20120220154900.R3579@besplex.bde.org> References: <201202200105.q1K15HRB024037@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r231923 - head/sys/kern X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 05:55:45 -0000 On Mon, 20 Feb 2012, Xin LI wrote: > Log: > Use uprintf instead of printf for the reason why a kernel module can not > be loaded. This way, the administrator can get response immediately from > the shell session rather than relying on dmesg. > > MFC after: 1 month But this way, the message doesn't get logged, and in fact doesn't go to either of the places where it went before (the low-level-console and the log). Its hard to think of many cases where either printf() or uprintf() is correct for system-related or security-related messages generated by applications. printf() spams the console, and uprintf() isn't logged. tprintf() would go to a slightly different controlling terminal than uprintf(), and optionally to the log. In sys/kern, uprintf() was only used for exec errors, and that is almost correct since the errors are application ones (there may be a problem if the application has no controlling terminal -- then the message is not printed anywhere). tprintf() is used mainly by nfs, and that use seems to be correct, except its soleness is incorrect. I don't really like my log files filling up with nfs messages, but at least the messages aren't lost. Outside of sys/kern, most uses of uprintf() except ones in ffs seem to be correct. I think tprintf() should be used in ffs, as in ufs. Most file systems use neither uprintf() nor tprintf(). uprintf() prints on the controlling terminal of the process, while tprintf() prints on the controlling terminal of the session (and optionally, the log). The difference between these controlling terminals is subtle (usually null). I think there is more likely to be a controlling terminal for the session, but if it is not for the process than it is less likely that someone is watching it. Bruce