On Tue Sep 08 2009 at 13:02:55 +0000, Christos Zoulas wrote: > In article <20090907174634.ga16...@cs.hut.fi>, > Antti Kantee <po...@netbsd.org> 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. 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 think Matt understood my extended offline explanation yesterday, so maybe he could chime in and summarize?
