From owner-svn-src-all@FreeBSD.ORG Mon Feb 20 09:44:15 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08121106564A; Mon, 20 Feb 2012 09:44:15 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id DF00A8FC12; Mon, 20 Feb 2012 09:44:14 +0000 (UTC) Received: from delta.delphij.net (unknown [IPv6:2001:470:83bf:0:221:5cff:fe6a:37bb]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 47BDC6FD2; Mon, 20 Feb 2012 01:44:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1329731054; bh=H5MUERkVnbPeOF2rEdpoXb83dhyGZujnjZY8StgwdXY=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=2bq6xJTUJ5D7cYGpfnvOW8XRpCV2a/ulYiA5KGe+rkYiTQP/ARNvw8QbLyB1Lkjnd kO6FQfKFRDZnZuU96gGPWZovtoobQQiI4r4Z5hAUcbKPrRNP3KLiZQg/3F5ABL30lr 6F+B43WNIBBMZTNG8wNigba4sZFBWnPrRwih8O5I= Message-ID: <4F4215E0.20908@delphij.net> Date: Mon, 20 Feb 2012 01:44:00 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Bruce Evans References: <201202200105.q1K15HRB024037@svn.freebsd.org> <20120220154900.R3579@besplex.bde.org> In-Reply-To: <20120220154900.R3579@besplex.bde.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, d@delphij.net, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Xin LI Subject: Re: svn commit: r231923 - head/sys/kern X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 09:44:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Bruce, On 02/19/12 21:55, Bruce Evans wrote: > 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. First of all thanks for your comments! > 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). The old behavior seems to be a little bit contradict with intuition, as the error message could be shown on a different TTY. What happens here would be, let's say the user is on ttyv1, and do a 'kldload foo' where foo.ko depends on a non-existent kernel module, the system would spit error on console (not ttyv1) and log it. > 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. I have found another issue so I've reverted this revision for now. I'll put together a new patchset for review. I'm not quite convinced with logging these events, though, since the kernel linker would return a error value if load is not successful, and we do not log e.g. ELF format errors, should kernel modules be treated differently here? Or should I use tprintf(.., LOG_ERR, ..) for these cases? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPQhXfAAoJEG80Jeu8UPuz/GYH/iGrO5VJsII1bKdnWg7teOtp ht/YlV2Su2mDNwBdxntlEnsh9G/wGjk+kC1rg/LzaqhJ1lZgukozP5OOL1uj3cST 4BBM2Y0I35nlI611Yj0lC08LMBeDzjM2miDcfNTZz3Yq5s7X2P1zcES6fGDcMZ2P J0b89hya7v5qwEfchk/0LeFi33pvUC3O0IP9sv0GDXfD96KpO6BXyI/hHn07qzYP oCSWIYqz64R7oj5bpdbcFGuskGRtjMG8+0AEiFfaLQ67k7F0L43zhZW51w8yK+5s 5zR+0x+Yziwsmeez+jhWx1fKwhfQX959tlErAaB0dt5f38weGDIKTRvo9q0RPWg= =n/O1 -----END PGP SIGNATURE-----