-----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 <delp...@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----- _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"