Re: CVS commit: src/sys/rump

["M. Warner Losh" <imp%bsdimp.com@localhost>]

In message: <20090908131801.GB17937%cs.hut.fi@localhost>
            Antti Kantee <pooka%cs.hut.fi@localhost> writes:
: On Tue Sep 08 2009 at 13:02:55 +0000, Christos Zoulas wrote:
: > In article <20090907174634.GA16124%cs.hut.fi@localhost>,
: > Antti Kantee  <pooka%NetBSD.org@localhost> wrote:
: > >On Tue Sep 08 2009 at 03:28:35 +1000, matthew green wrote:
: > >> 
: > >>    Module Name:  src
: > >>    Committed By: pooka
: > >>    Date:         Mon Sep  7 13:02:37 UTC 2009
: > >>    
: > >>    Modified Files:
: > >>          src/sys/rump: Makefile.rump
: > >>    
: > >>    Log Message:
: > >>    Always define __NetBSD__ (for builds on non-NetBSD)
: > >> 
: > >> 
: > >> when does this happen?  even builds on non-NetBSD should
: > >> end up here with a compiler that defines __NetBSD__.
: > >
: > >When you are building the binaries to be used as libraries on non-NetBSD,
: > >i.e. not building NetBSD itself.
: > 
: > Then perhaps we should be using a different CPP symbol?
: 
: No, __NetBSD__ is right.  For all purposes, code in the rump kernel *is*
: NetBSD.  E.g. if you have #ifdef __NetBSD__ in a kernel driver which
: was imported from $OtherOS, you must have the rump version think it is
: running on NetBSD, since it technically speaking is.  The difference to
: most cpp symbols is merely that __NetBSD__ comes from the compiler instead
: of from the kernel headers.  Of course param.h could define something like
: __I_am_the_NetBSD__ and we could test against that in all of our NetBSD
: kernel code, but I don't see any benefit, especially since __NetBSD__
: is a well established practise even outside NetBSD developers.

__NetBSD__ is the *COMPILER* environment.  Depending on it is *BAD*.
You need to use a different symbol.  This is a bug in the NetBSD code
now.  __NetBSD__ isn't, and never has bene, the KERNEL.

: Maybe it's easier to understand this issue if you think of rump as a
: highly componentized OS running inside a virtual machine.  Just instead
: of qemu or xen or what have you, your vmm is a process -- nobody is
: saying xen code shouldn't use __NetBSD__, are they?

I'd say that it shouldn't...

: I think Matt understood my extended offline explanation yesterday,
: so maybe he could chime in and summarize?

Maybe __NetBSD_Version__ should be used instead?  Its clearly NetBSD
kernel build environment specific (since it comes from sys/parma.h)
and doesn't muddy the waters with the differences between the
different BUILD systems.

Warner