From owner-freebsd-arch Wed Nov 15 10:45: 6 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29DF837B479; Wed, 15 Nov 2000 10:45:03 -0800 (PST) Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1DD86E2EE9; Wed, 15 Nov 2000 10:43:45 -0800 (PST) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id KAA27719; Wed, 15 Nov 2000 10:38:23 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda27717; Wed Nov 15 10:38:03 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.1/8.9.1) id eAFIbsn91737; Wed, 15 Nov 2000 10:37:54 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdG90432; Wed Nov 15 10:37:25 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.1/8.9.1) id eAFIbPn69154; Wed, 15 Nov 2000 10:37:25 -0800 (PST) Message-Id: <200011151837.eAFIbPn69154@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdS68834; Wed Nov 15 10:36:43 2000 X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cy To: "John W. De Boskey" Cc: Terry Lambert , Eivind Eklund , John Baldwin , arch@FreeBSD.ORG Subject: Re: Turning on debugging in GENERIC In-reply-to: Your message of "Wed, 15 Nov 2000 13:08:27 EST." <20001115130827.A1762@bsdwins.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Nov 2000 10:36:43 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20001115130827.A1762@bsdwins.com>, "John W. De Boskey" writes: > ----- Terry Lambert's Original Message ----- > > > I'm not sure I'm happy about DIAGNOSTIC; unless changed, it > > > significantly change some codepaths, and it produce output about system > > > state, not just extra checks. Any plain checks that are under DIAGNOSTIC > is > > > there through a miscommunication or not finished conversion, anyway; it > > > should only be causing extra debug output. > > > > I am not happy about the code path changes it engenders. > > > > However, I see the need for turning it on, during a period > > where extreme instability of snapshots is anticipated/likely, > > and I think that's the reason it is being proposed. > > > > Many people "try" -current on small scratch disks that they > > install from snapshots, rather than polluting their local > > trees with -current bits, particularly since the answer to > > their bug reports is pretty much to ignore them and tell the > > reporter to "resup" or ask "have you tried the snapshot?". > > > > I think that having the DIAGNOSTIC option is OK; on the other > > hand, I somewhat wish that this would move from a GENERIC > > file into a SNAPSHOT file, and that snapshots be configured > > from there instead of GENERIC, since reverting this back and > > forth every six months, instead of changing a cron script, > > seems like a real waste of repository commits. > > I tend to disagree here... Please don't build snapshots with > this code turned on. > > Yes, run with these options turned on by default in GENERIC. > > I think building snapshots with a SNAPSHOT kernel is an > interesting idea, but it leads to dual maint issues where > GENERIC gets updated, but SNAPSHOT does not. How about a sed script that generates SNAPSHOT from GENERIC. Then there are no dual maint issues. When buildkernel KERNEL=SNAPSHOT is performed, the script is run to generate SNAPSHOT from GENERIC. > > > > > All that said, let's not downplay the code path changes: I > > have worked in places where I had to be "the grumpy old man > > of the source tree", when the code would not build due to > > "DEBUG" _not_ being asserted during the build, or other such > > diagnostic manifest constants. I really dislike manifest > > constants in all forms, because of this, and prefer link or > > run time tuning. > > Can we turn some of these options into sysctl variables and > remove them as kernel config options? > > sysctl -w kern.diagnostics=1 > > with the appropriate code changes? (Yes, minor perf loss)... Could even be a major perf loss. My vote is no. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message