svn commit: r231923 - head/sys/kern
Xin Li
delphij at delphij.net
Mon Feb 20 09:44:15 UTC 2012
-----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 at 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-----
More information about the svn-src-head
mailing list