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