From owner-cvs-all@FreeBSD.ORG Fri Nov 14 08:30:32 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D0D216A4E1 for ; Fri, 14 Nov 2003 08:30:32 -0800 (PST) Received: from mail.speakeasy.net (mail8.speakeasy.net [216.254.0.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8672143FD7 for ; Fri, 14 Nov 2003 08:30:29 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 31945 invoked from network); 14 Nov 2003 16:30:23 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 14 Nov 2003 16:30:23 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id hAEGUKEW006481; Fri, 14 Nov 2003 11:30:21 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200311141604.hAEG4BCg041862@repoman.freebsd.org> Date: Fri, 14 Nov 2003 11:30:17 -0500 (EST) From: John Baldwin To: Brian Feldman X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: RE: cvs commit: src/sys/conf kern.post.mk kmod.mk X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2003 16:30:32 -0000 On 14-Nov-2003 Brian Feldman wrote: > green 2003/11/14 08:04:11 PST > > FreeBSD src repository > > Modified files: > sys/conf kern.post.mk kmod.mk > Log: > Include opt_global.h in the modules build, when building from a normal > kernel build. This makes it possible for me not to get pissed off that > random.ko crashes the system trying to rdtsc() when the i386/cpu.h > support code decides it's okay to call that op when neither I386_CPU or > I486_CPU is defined. I guess it also makes WITNESS/INVARIANTS defines > get picked up by the modules. WITNESS doesn't matter as all calls to it are done in the actual locking code itself which does not lives in modules. Modules always call the locking functions and don't inline locking operations. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/