Re: CVS commit: src/share/man/man4

2011-09-03 Thread John Nemeth
On Jan 20,  1:58pm, Jukka Ruohonen wrote:
} On Tue, Aug 30, 2011 at 10:10:05AM -0500, David Young wrote:
}  
}  The driver should be converted, however, I don't think that there is
}  a case for bluntly removing bktr(4), 
} 
} Yes, I was corrected already (the conversion should go towards video(4)).
} 
} But as always, it is about picking the good defaults for GENERIC.

 In NetBSD, GENERIC kernels generally contain everything that could
possibly be useful and doesn't cause problems (some newer drivers are
buggy, some interfere with other devices, and some have caused damage
to hardware).  This means the question is very simple:  is the driver
brand new, or does it cause problems in some way?  If the answer is no
to both questions, then the driver is included; there are no other
factors to the decision.  Note that cause problems in some way does
not include consuming resources such as wired kernel memory.

}-- End of excerpt from Jukka Ruohonen


Re: CVS commit: src/share/man/man4

2011-09-03 Thread Jukka Ruohonen
On Fri, Sep 02, 2011 at 11:23:08PM -0700, John Nemeth wrote:
  In NetBSD, GENERIC kernels generally contain everything that could
 possibly be useful and doesn't cause problems (some newer drivers are
 buggy, some interfere with other devices, and some have caused damage
 to hardware).  This means the question is very simple:  is the driver
 brand new, or does it cause problems in some way?  If the answer is no
 to both questions, then the driver is included; there are no other
 factors to the decision.  Note that cause problems in some way does
 not include consuming resources such as wired kernel memory.

So if everything is clear and rational, care to explain why for instance
GATEWAY and IPSEC are commented out? And as said, my drivers will be an
exception.

- Jukka.


Re: CVS commit: src

2011-09-03 Thread Warner Losh

On Sep 2, 2011, at 11:09 AM, David Laight wrote:

 On Thu, Sep 01, 2011 at 08:19:07AM +0100, Iain Hibbert wrote:
 On Wed, 31 Aug 2011, Warner Losh wrote:
 
 In the absence of both the prototype and a cast, NULL (which can be 0)
 will be passed as an int, not as a pointer.
 
 NetBSD C headers define NULL as ((void *)0), and our Makefiles use -Wall
 (includes -Wimplicit-function-declaration) to avoid such situations..
 
 ISTR that ansi C (or some recent version of it) does require that
 NULL be a pointer constant - so that it gets passed correctly to
 varargs functions that expect a data pointer.

C89 and C99 don't require this.  #define NULL 0 is a conforming definition.

C1X draft N1570 still has 6.3.2.3 An integer constant expression with the 
value 0, or such an expression cast to type void *, is called a null pointer 
constant. and 7.19 The macros are NULL which expands to an 
implementation-defined null pointer constant which means #define NULL 0 is 
still a conforming definition.

C++'s new standard is different though.

 Without function prototypes this is a bigger problem, especially
 since (char *)0 isn't a useful definition!
 This is where 'lint' comes in handy, since it (effectively) checked
 that args matched the inferred prototype ...
 
   David
 
 -- 
 David Laight: da...@l8s.co.uk