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