Date: Fri, 17 Nov 2000 23:04:32 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jhb@FreeBSD.org (John Baldwin) Cc: tlambert@primenet.com (Terry Lambert), chat@FreeBSD.org, nate@yogotech.com Subject: Re: Turning on debugging in GENERIC Message-ID: <200011172304.QAA05502@usr08.primenet.com> In-Reply-To: <XFMail.001117115349.jhb@FreeBSD.org> from "John Baldwin" at Nov 17, 2000 11:53:49 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> To clarify at least one thing, the reason that I personally would > like to have INVARIANTS and a few other options in the kernel are > due to the fact that the new SMP code is not entirely stable, and > can give some rather cryptic crashes and behaviors that are > symptoms of other harder to find problems. Enabling extra sanity > checks results in many of these root problems being found easier > as a bug is spotted sooner before it heads off into the weeds and > breaks something else. A panic telling you that you that > chooseproc() returned NULL and you are trying to schedule the NULL > proces is much more helpful than getting a panic later on after > you have executed some unknown amount of random code before you > get a trap 12 off in lala land. This is all solid engineering ground. I only had reservations about "DIAGNOSTIC", with regards to it changing code paths. I don't think that "DIAGNOSTIC" should be included. My only comment on the process was to suggest that the options not be in "GENERIC", per se. I suggested the use of the name "SNAPSHOT", instead, e.g.: >-- Makefile fragment ------------------------------------------- SNAPSHOT: GENERIC cp GENERIC SNAPSHOT echo "option FOO" >> SNAPSHOT echo "option FEE" >> SNAPSHOT ... <-- Makefile fragment ------------------------------------------- Obviously, the paths would have to be corrected, but you could put whatever additional options you wanted into a snapshot during the build process, without modifying "GENERIC" to the point that it was no longer generic. > Now, as for snapshots, we do have a snapshot server > (current.FreeBSD.org) that keeps roughly the last 3 months of > snapshots. Boot floppies don't have room for all the debugging > info, so boot floppy kernels won't have the extra debugging, > however the kernel that boots after the system is installed will. My suggestion here was a bit more complex. Having symbols there is not the same as having a -g compiled kernel with the ability to do source exeamination of a crash dump, or even a crash report with a program counter. My suggestion was to change the (perhaps snapshot-only, perhaps not) build process to build kernel's -g. The process would be: 1) Build a -g kernel (kernel.debug) 2) strip -d -o kernel.nodebug kernel.debug 3) strip -o kernel kernel.nodebug #3 is what goes on the floppies; #2 is what gets installed. #1 is a _new_ file that's added seperately to the FTP archive, so that a developer could better analyse a crash dump or bug report. > Also note that conning^Wpersuading someone to implement a > suggestion you may make qualifies as "implements" in this case. Uh, how about changing the build and archival process to include #1? It's unfortunately something I have no control over at all. We could do a survey in 6 months, assuming people start getting pointed to snapshots to use for bug reporting pruposes when a bug occurs. If it turns out that it hasn't bee useful then you can revert the process, no harm, no foul. As far as the "SNAPSHOT"/"GENERIC" thing, I think it's new implementation, either way, so going one way instead of the other is not a hardship. PS: Are the snapshot dates accurate source tree dates? They would need to be, if you wanted to rebuild a particular snapshot form the source tree, and get an identical image (except for the file dates, of course)... 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-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011172304.QAA05502>