Date: Fri, 10 Nov 2000 18:57:36 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: duan@cs.umn.edu (Zhenhai Duan) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: printf() Message-ID: <200011101857.LAA24569@usr08.primenet.com> In-Reply-To: <Pine.LNX.4.10.10011092306100.24982-100000@barber.cs.umn.edu> from "Zhenhai Duan" at Nov 09, 2000 11:08:46 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> A simple question: > > Does the kernel function printf() flushes the output immediately, or it is > possible some data is buffered somewhere and gets lost without printing > to the console? like the corresponding funtion in the c library. There is no buffering comparable to that of the stdio package; in other words, there is no such thing as an fflush() or setbuf() call. There has been some discussion of bufering of console output, with the buffer list to be used as a synchronization point, so that SMP systems, kernel threads, and interrupt handlers can't stomp on each other when one is in the middle of console I/O; should that work be done and incorporated, the console I/O will definitely be buffered, in the stdio sense, and a "spin until queue drains, yielding to the console output routine" may find its way in, as an aid to debugging kernel problems, which could otherwise be hidden by the queueing: a kernel fflush(). As things currently sit, it's possible to take an interrupt in the middle of output, and truncate it, if the interrupt handler has a bug that forces it into a tight loop, or otherwise locks up the machine. Similarly, output in an interrupt handler might (rarely) stomp in the middle of output in progress from elsewhere; console output at interrupt level is discouraged. Depending on the console output you are talking about, if it's coming from user space, all bets are off: user space console I/O may be buffered by whatever program doing the output, and some programs which output to the console have very long latencies, which you might also see (e.g. syslogd). Console messages that are sent from the kernel are usually sent to the diagnostic log. This is the log reported by dmesg, and is implemented using a buffer in memory, which is expected to survive over a boot. Some BIOS RAM test methods used to prevent this; I am unsure of how this is stored over reboots in the current code, and whether it is reliable or not on particular hardware. This is the information that is reported by the "dmesg" command. Finally, if you are talking about the console log, those outputs are inddeed buffered, through syslog. In addition, the commits of this data to the log file are not entirely synchronous. This means that you can not really depend on the console log contents to be 100% accurate at any given instance. So if what you are trying to do is diagnose a system crash from the console log in /var/messages (for example), then you will be out of luck. If dmesg data survives reboots for you, then you will be much happier using that instead of the console log (default: /var/log/messages). I hope this was useful; there really is very little documentation that is accurate about this type of area of FreeBSD internals, so it was probably OK for you to post your question here rather than questions, even though you are probably asking about what you suspect is your problem, instead of asking your real question. Hope this helps, and hope anyone who has any corrections to this wil provide them, since this type of documentation needs to be collected somewhere, and the mailing list archives seem to be the most appropriate place. Maybe we can set up an arch-doc list, which we can cross-post these responses to via Bcc:, without incurring the wrath of the mailing list manager? An archive of such things (my contributions in this area are minor, trust me) would be a good thing; PHK posted a nice internals description the other day that I would not mind having archived for eternity, without it taking up space in my email archive. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011101857.LAA24569>