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

From: Havard Eidnes <he@NetBSD.org>
To: gnats-admin@netbsd.org
Cc: netbsd-bugs@netbsd.org
Subject: Re: bin/32907: IPF user-land ipsend defines _KERNEL, and fails to
 build for vax
Date: Tue, 28 Feb 2006 11:05:31 +0100 (CET)

 Some more input on this problem.
 
 The reason this isn't a problem on other platforms is that
 apparently no other platforms ends up including <sys/device.h>.
 On vax, though, when _KERNEL is defined, the include order goes
 like this:
 
 <sys/file.h>
   <sys/lock.h>
     <machine/lock.h>
       <machine/cpu.h>
         <sys/device.h>
 
 and <sys/file.h> is explicitly surrounded by _KERNEL by
 ipsend/sock.c, apparently mostly to get "struct file" defined.
 
 Further attempts to work around this problem by including
 <sys/types.h> early with _KERNEL defined (to get boolean_t
 defined) results in a link failure for the kernels for the alpha
 architecture.  The reason is that bswap16() is not renamed when
 compiled under _KERNEL, whereas it is renamed for user-land, and
 it is referenced through use of ntohs() in ipsend/sock.c.
 
 It currently appears to be impossible to include <sys/types.h>
 and <sys/endian.h> (and by extension <sys/bswap.h>) under
 different definitions of _KERNEL.
 
 The end result is that with the current code and attempts at a
 point fix isolated to the IPF source for this build problem, we
 get to choose whether we want to break the build for vax or for
 alpha, and currently the vax build remains broken.
 
 
 I have seen comments to the effect that the sort of games IPF
 plays with defining _KERNEL in user-land code is both ugly and
 highly non-portable, and I would say that this demonstrates at
 least the latter.
 
 
 Regards,
 
 - H=E5vard