From owner-freebsd-chat Fri Nov 17 15: 5:20 2000 Delivered-To: freebsd-chat@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id D60D737B4C5; Fri, 17 Nov 2000 15:05:11 -0800 (PST) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id QAA10054; Fri, 17 Nov 2000 16:04:05 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpdAAAeEaOlt; Fri Nov 17 16:03:37 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id QAA05502; Fri, 17 Nov 2000 16:04:32 -0700 (MST) From: Terry Lambert Message-Id: <200011172304.QAA05502@usr08.primenet.com> Subject: Re: Turning on debugging in GENERIC To: jhb@FreeBSD.org (John Baldwin) Date: Fri, 17 Nov 2000 23:04:32 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), chat@FreeBSD.org, nate@yogotech.com In-Reply-To: from "John Baldwin" at Nov 17, 2000 11:53:49 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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