Date: Mon, 20 Feb 2012 16:55:40 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Xin LI <delphij@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r231923 - head/sys/kern Message-ID: <20120220154900.R3579@besplex.bde.org> In-Reply-To: <201202200105.q1K15HRB024037@svn.freebsd.org> References: <201202200105.q1K15HRB024037@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120220154900.R3579>