Re: kern/43063: Please delete __NetBSD_Prereq__() from <sys/param.h>

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/43063; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/43063: Please delete __NetBSD_Prereq__() from <sys/param.h>
Date: Sun, 28 Mar 2010 16:50:58 +0700

     Date:        Sat, 27 Mar 2010 19:35:02 +0000 (UTC)
     From:        David Holland <dholland-bugs%NetBSD.org@localhost>
     Message-ID:  <20100327193502.6F2DF63B11D%www.NetBSD.org@localhost>
 
   |   >  if there realy is a need for such a test in pkgsrc world. Pkgsrc 
folks?
   |  
   |  In general I don't think there is.
 
 I certainly don't mind if some new macros are added, but I thought all this
 stuff was for LKMs (originally) and, I guess, for modules now.
 
 It really makes no sense for pkgsrc (or any application) to test to see what
 kernel version is running - that's useless information, aside from the odd
 ioctl (and similar) for which it is easier to test to see if the ioctl name
 is defined, knowing what kernel is running is of no interest if the userland
 API to the kernel is older - I have run a NetBSD 5 kernel with NetBSD 3.* based
 libc, and NetBSD current (5.99.*) kernels with NetBSD 4 based libc - and
 all of that is supposed to and (some threading issues aside) does work.
 
 An application that looks at __NetBSD_Version__ from <sys/param.h> and
 decides that means it is 5.99.* and so "just knows" that time_t is 64 bits,
 or whatever else current has that's different from older systems is then
 going to get a shock when time() (and all the time fields in kernel interface
 structs) keep on being 32 bits using the compat interfaces into the kernel.
 
 I really don't think we ought to be doing anything to encourage pkgsrc
 (or any applications, aside perhaps from a few kernel monitoring type) from
 ever finding out what kernel version happens to be running.
 
 LKMs are dead, so we don't have to worry about those any more.
 
 That just leaves modules, and I think the people building those are
 quite able to create a macro to do whatever test on __NetBSD_Version__
 that might need, if they ever need one.
 
 So, for now, I think I'd suggest just deleting the worse than useless
 __NetBSD_Prereq__ macro, and just wait to see if anything else is needed
 rather than presuming that something will be.
 
 kre