From owner-cvs-src@FreeBSD.ORG Wed Aug 30 22:12:08 2006 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 049A216A4DE; Wed, 30 Aug 2006 22:12:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FB6A43D45; Wed, 30 Aug 2006 22:12:07 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k7UMC1dF018966; Wed, 30 Aug 2006 18:12:01 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Ruslan Ermilov Date: Wed, 30 Aug 2006 18:11:40 -0400 User-Agent: KMail/1.9.1 References: <200608292036.k7TKaXBp044347@repoman.freebsd.org> <200608301320.33720.jhb@freebsd.org> <20060830205155.GB11411@rambler-co.ru> In-Reply-To: <20060830205155.GB11411@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608301811.40837.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 30 Aug 2006 18:12:04 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1776/Wed Aug 30 16:37:14 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Bruce Evans Subject: Re: cvs commit: src/sys/sys sx.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2006 22:12:08 -0000 On Wednesday 30 August 2006 16:51, Ruslan Ermilov wrote: > On Wed, Aug 30, 2006 at 01:20:32PM -0400, John Baldwin wrote: > > On Wednesday 30 August 2006 05:37, Bruce Evans wrote: > > > On Tue, 29 Aug 2006, John Baldwin wrote: > > > > > > > jhb 2006-08-29 20:36:33 UTC > > > > > > > > FreeBSD src repository > > > > > > > > Modified files: > > > > sys/sys sx.h > > > > Log: > > > > The _sx_assert() prototype should exist if either of INVARIANTS or > > > > INVARIANT_SUPPORT is defined so you can build a kernel with > > > > INVARIANT_SUPPORT, but build a module with just INVARIANTS on. > > > > > > No it shouldn't. INVARIANT_SUPPORT is a documented prerequisite for > > > INVARIANTS. So is the resulting requirements for using INVARIANTS to > > > create non-modular "modules": From /sys/conf/NOTES: > > > > > > # The INVARIANT_SUPPORT option makes us compile in support for > > > # verifying some of the internal structures. It is a prerequisite for > > > ^^^^^^^^^^^^^^^^^^^^^^^^ > > > # 'INVARIANTS', as enabling 'INVARIANTS' will make these functions be > > > ^^^^^^^^^^^^ > > > # called. The intent is that you can set 'INVARIANTS' for single > > > # source files (by changing the source file or specifying it on the > > > # command line) if you have 'INVARIANT_SUPPORT' enabled. Also, if you > > > ^^^^^^^^^^^^ > > > # wish to build a kernel module with 'INVARIANTS', then adding > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > # 'INVARIANT_SUPPORT' to your kernel will provide all the necessary > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > # infrastructure without the added overhead. > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > However, INVARIANTS is a fairly bogus option. Last time I looked > > > (long ago) it only controlled a small amount of kernel bloat, and there > > > are probably many other functions that are defined unconditionally else > > > modules with INVARIANTS would be more broken. > > > > Err, the text in NOTES is probably wrong then. The idea is that INVARIANTS > > enables various assertions. Similar to how NDEBUG turns off assert() (but > > inverted). The purpose of INVARIANT_SUPPORT is to provide any needed > > assertion-supporting code (such as _foo_assert()) macros in the kernel. > > Thus, if I want to run any code that uses INVARIANTs, I need to have a kernel > > built with INVARIANT_SUPPORT. However, I might build only selected portions > > of the kernel with INVARIANTS. For example, I might build none of the kernel > > with INVARIANTS, but only a kernel module for a device driver being developed > > or a test kernel module (like my crash.c and crash2.c.). > > > I read what you've written precisely as what was quoted from NOTES. > I.e., to be able to compile some bit with INVARIANTS, the kernel > should have been compiled with INVARIANT_SUPPORT. _sx_asser() is > part of that support, not a "user" of invatianted code. If some > code that uses sx locks needs to be "invarianted", it can be > compiled with only "options INVARIANTS". > > I fail to see how your commit follows this, however. What you have > committed may eventually turn into "if option INVARINANTS is enabled > when compiling a kernel, automatically enable the INVARIANT_SUPPORT > option" -- when all INVARIANT_SUPPORT ifdefs will be converted to > INVARIANT_SUPPORT || INVARIANTS. No. The _sx_assert() _function_ is only #ifdef INVARIANT_SUPPORT in kern_sx.c. However, the _sx_assert() function _prototype_ is used both in kern_sx.c when compiling, but also by consumers of the sx_assert() macro defined in sys/sx.h. That is, the prototype is needed for both cases, 1 is so kern_sx.c has a prototype for the function it declares, this requires INVARIANT_SUPPORT; 2 is for all the users of sx_assert() in the tree, which map sx_assert() to a call to _sx_assert() if INVARIANTS is defined. -- John Baldwin