On Mon, Mar 29, 2010 at 8:27 PM, John Baldwin <j...@freebsd.org> wrote: >> To developers: what incentives would help get this issue well-needed >> attention? This problem makes kernel debugging, panic analysis, and >> other console-oriented viewing basically impossible. > > I was recently going to look at it. The somewhat drastic approach I was going > to take was to add a simple serializing lock around trap_fatal() and a few > other places that do similar block prints (e.g. mca_log()). One of the issues > with fixing this in printf itself is that you'd want probably want to > serialize complete lines of text on a per-thread basis. You would want to be > able to accumulate this line of text across multiple calls to printf (think of > it as line-buffering ala stdio). However, some folks may be nervous about > printf not printing things immediately. > > The other issue is that lots of code assumes it can call printf from anywhere > and everywhere. Mostly this just means that if you add locking and line- > buffering to printf(9) you have to be very careful to make sure it works in > odd places. Probably a lot of this could be solved by deferring things like > trap_fatal() until panic() has already been called (which is bde's preferred > solution I think).
How about serializing all printf(9) through a dedicated kernel thread? Maybe something as flexible as syslogd for kernel space (klogd), that could also redirect output to a file, to a serial console etc...? > John Baldwin -cpghost. -- Cordula's Web. http://www.cordula.ws/ _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
