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