cvs commit: src/sys/sys sx.h

[Ruslan Ermilov]

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.


Cheers,
-- 
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20060830/065ade70/attachment.pgp