Christoph Egger, le Tue 19 Jan 2010 10:25:10 +0100, a écrit :
> On Monday 18 January 2010 12:11:05 Samuel Thibault wrote:
> > Christoph Egger, le Mon 18 Jan 2010 11:42:43 +0100, a écrit :
> > > --- a/Makefile.target
> > > +++ b/Makefile.target
> > > +ifdef CONFIG_STUBDOM
> > > +CFLAGS += -I$(MINI_OS-ROOT)/include
> > > +endif
> >
> > Isn't that already done by the stubdom/ Makefile? Or put another way,
> > why is it needed on netbsd when it is not on linux?
>
> To make MiniOS and Stubdom build on NetBSD, I have to restructure the headers.
> This work is not yet 100% complete but so far I can tell, with the
> restructuring done, you also need it on Linux.
I guess Keir could prefer to see both patches submitted at the same
time. What I don't understand is why this hunk is needed when at the
same time you are adding mini-os/ in include paths, which will permit
to just add to -isystem a directory containing a mini-os symlink to
MiniOS's headers, to avoid polluting the include namespace with mini-os
headers like this hunk does.
> > > --- a/hw/xen_machine_fv.c
> > > +++ b/hw/xen_machine_fv.c
> > > @@ -40,8 +40,11 @@
> > > +
> > > +#ifndef CONFIG_STUBDOM /* defined in <mini-os/x86/os.h> */
> > > #define test_bit(bit,map) \
> > > (!!((map)[(bit)/BITS_PER_LONG] & (1UL << ((bit)%BITS_PER_LONG))))
> > > +#endif
> >
> > Same question: how is it that it is not needed on linux?
>
> The actual question here is: Why does gcc on Linux not barf about
> redeclaration?
It does, but IIRC not about this one, that's why I'm asking.
> > > --- a/vl.c
> > > +++ b/vl.c
> > > @@ -42,6 +42,7 @@
> > > +#include "dma.h"
> >
> > Why?
>
> Fixes warning about missing prototypes (i.e. for dma_helper_init)
Doesn't it impact upstream too? It then should be submitted upstream
instead. Ian prefers to keep the diff with upstream as low as possible,
don't add noise to it :)
> > > index 50dfb6b..1a6e445 100644
> > > --- a/qemu-common.h
> > > +++ b/qemu-common.h
> > > @@ -9,6 +9,8 @@
> > > +#include "config-host.h"
> >
> > Why?
>
> To get the right socket declarations and fix loop inclusion of
> libc and minios sockets.
See below.
> > > --- a/vnc.c
> > > +++ b/vnc.c
> > > @@ -32,8 +32,8 @@
> > > -#ifdef CONFIG_STUBDOM
> > > +#if defined(CONFIG_STUBDOM) && defined(__Linux__)
> >
> > I do not understand these. netfront.h is not linux-specific.
>
> netfront.h belongs to lwip. What is wrong with using libc ?
No. netfront.h belongs to MiniOS. Is your libc able to use netfront to
be able to send/receive network packets?
We already discussed about it on xen-devel. Ian, Stefano and I agreed
that we do not want to maintain several kinds of libc to be used in stub
domains. They are already difficult enough to debug that we don't want
to have several environment with varying kinds of bugs. You said there
were erroneous linuxish assumption currently done. Fine, please show
them, and fixing them will be useful for all ports, not only NetBSD.
> > > -#ifndef CONFIG_STUBDOM
> > > +#if !defined(CONFIG_STUBDOM) || defined(__NetBSD__)
> >
> > I do not understand these either. Stub domains do _not_ have
> > a working SO_REUSEADDR.
>
> Same here: What is wrong with using libc ?
Same answer.
> > > index fcf60c3..88f84cd 100755
> > > --- a/xen-setup-stubdom
> > > +++ b/xen-setup-stubdom
> > > @@ -36,7 +36,15 @@ cat <<END >config-host.h.new
> > > #define CONFIG_QEMU_SHAREDIR "${SHAREDIR}/xen/qemu"
> > > #define HOST_I386 1
> > > #define HOST_LONG_BITS 32
> > > +#ifdef __Linux__
> > > #define HAVE_BYTESWAP_H 1
> > > +#endif
> > > +#ifdef __NetBSD__
> > > +#define _BSD 1
> > > +#define HAVE_MACHINE_BSWAP_H 1
> > > +#define HAVE_IOVEC 1
> > > +#define O_LARGEFILE 0
> > > +#endif
> >
> > I'm not sure about that either. Do you realize that stubdomains are not
> > running linux or BSD but MiniOS?
>
> This change is about *building* stubdom on Linux or BSD.
No. It's about *cross-building* stubdom on Linux or BSD. MiniOS _does_
have byteswap.h, newlib doesn't have iovec, etc. etc. Maybe your libc
doesn't/does, but see above.
Samuel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home