Date: Sun, 11 May 2003 17:08:23 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: freebsd-current@freebsd.org Subject: Re: LOR with -current Message-ID: <20030511170706.F74671@gamplex.bde.org> In-Reply-To: <20030510141840.Q2955@gamplex.bde.org> References: <20030508.124929.74756191.haro@kgt.co.jp> <20030508.102242.72244093.imp@bsdimp.com> <20030508.111836.130233489.imp@bsdimp.com> <20030510141840.Q2955@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[Resending with trimmed Cc: after second bounce] On Thu, 8 May 2003, M. Warner Losh wrote: > In message: <16058.36990.299231.566625@grasshopper.cs.duke.edu> > Andrew Gallatin <gallatin@cs.duke.edu> writes: > : > : M. Warner Losh writes: > : > That reminds me, would anybody object if I were to hack traceback so > : > that it would actually put the traceback in the dmesg buffer when not > : > called from ddb? Yes. No hacks please. See old mail about how to implement this not very hackishly (basically s/db_printf/printf/g, and change printf to act like the old db_printf iff db_active is set; this would also fix the bug of forgetting to use db_printf in ddb commands and reduce the bugs for abusing non-ddb commands as ddb commands). > : FWIW, I think that tracebacks generated from DDB_TRACE should also > : go into the dmesg buffer. It would save quite a few initial exchanges > : with users.. I think that DDB_TRACE shouldn't have been committed until it did this. > Does anybdoy know why the ddb output doesn't go into the dmesg buffer > in general? It sure would save me a lot of grief as well if it did. Yes. 1. The message buffer (and some other aspects of printf() as opposed to db_printf()) is highly non-reentrant and lock-deficient. This is broken in general. printf() can panic when it is called in certain not very unusual contexts, and ddb is often needed in these contexts. Also, using ddb in the relatively unusual context of debugging the message buffer itself would cause unbounded recursion if ddb output always went to the message buffer. 2. ddb output tends to be large and not very useful. It can push normal kernel messages (not to mention ddb messages) out of the message buffer before they can be seen by syslog. Just thought of another problem: the traceback can trap if it gets confused about the stack frame and/or the number of args. In ddb context, these traps are handled properly using setjmp() (except trap() barfs about them unsafely and unusefully using ordinary printf before it reenters ddb). This safety harness is missing if the traceback is done outside of ddb. You really don't want debugging messages about a problem compounding the problem. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030511170706.F74671>