Source-Changes-D archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/rump
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
Home |
Main Index |
Thread Index |
Old Index