WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: Pesky '#define current' in mini-os/sched.h

Samuel Thibault <samuel.thibault@xxxxxxxxxxxx> writes:

> Ferenc Wagner, le Tue 28 Apr 2009 20:47:41 +0200, a écrit :
>> Samuel Thibault <samuel.thibault@xxxxxxxxxxxx> writes:
>> > Ferenc Wagner, le Tue 28 Apr 2009 19:57:07 +0200, a écrit :
>> >> newlib-1.16.0/newlib/libc/include/sys/unistd.h defines _PC_VDISABLE.
>> >> It even has an fpathconf implementation in libc/sys/linux.  Is there a
>> >> way to get that work or had I better stub this one, too?
>> >
>> > Oh, right it's not defined in the linux/ part.
>> > That one should be fine indeed.
>> 
>> Do you know offhand why it isn't found?
>
> What do you refer to by "it"?

The fpathconf implementation.

> _PC_VDISABLE is in the generic part, so that's why ncurses sees it.
> fpathconf is in the linux/ part, so that's why it's not compiled in.

Ah, I wasn't aware of this distinction.

> Just take that implementation and it will get compiled in.

Sorry for sounding dense...  How do I "take that implementation"?  I
guess you don't mean cut&paste, do you?

>> For now I configured out database access and compiled in some fallbacks.
>
> Ok, that should be fine.  In that case, maybe you should rather stub
> access() as always failing, as it's not supposed to read files.

Not for the ncurses library, but maybe for something else...

>>> Now, I'm wondering about the ncurses requirement: is grub2 really
>>> using it for the bootloader, not just for the userland tool?
>> 
>> No, it does not require it for the bootloader.  My plan is to port the
>> grub-emu userland tool instead, and finally patch kexec on that, just
>> like you did with grub1.
>
> Err, I didn't port the userland tool, I ported the bootloader.  The
> userland grub1 tool does not even include code to boot kernels,
> actually...

Yes, it's all the same for grub2.  With "just like you did" I meant
patching in kexec, so that the grub-emu userland tool can actually
boot kernels.  You also needed to patch kexec onto the grub1 boot
loader (but not the userland tool).

>>>> I may be blind, but there's no -l linker option in stubdom/Makefile.
>>>
>>> Sure, but in qemu/ there is a -lz linker option.  Just the usual way,
>>> that is.
>> 
>> There's no qemu/ in the 3.3.1 tree, as far as I can see.
>
> It's a symlink to the ioemu/ tree, yes, I didn't mean a precise
> directory name, just vaguely evoking ioemu.

OK, in ioemu I found

tapdisk-ioemu: tapdisk-ioemu.c cutils.c block.c block-raw.c block-cow.c 
block-qcow.c aes.c block-vmdk.c block-cloop.c block-dmg.c block-bochs.c 
block-vpc.c block-vvfat.c block-qcow2.c hw/xen_blktap.c osdep.c
        $(CC) -DQEMU_TOOL $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) $(LDFLAGS) 
$(BASE_LDFLAGS) -o $@ $^ -lz $(LIBS)

and

qemu-img$(EXESUF): qemu-img.c cutils.c block.c block-raw.c block-cow.c 
block-qcow.c aes.c block-vmdk.c block-cloop.c block-dmg.c block-bochs.c 
block-vpc.c block-vvfat.c block-qcow2.c
        $(CC) -DQEMU_TOOL $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) $(LDFLAGS) 
$(BASE_LDFLAGS) -o $@ $^ -lz $(LIBS)

but neither is applicable to c-stubdom, where the Makefile stops at
creating an archive.  I can't add -lncurses there...  And generally I
feel like being on a totally wrong track, as this part doesn't seem to
involve minios at all.

>>>> $(NCURSES_STAMPFILE): ncurses-$(XEN_TARGET_ARCH) $(NEWLIB_STAMPFILE)
>>>>         ( cd $< && \
>>>>           CFLAGS="$(TARGET_CPPFLAGS) $(TARGET_CFLAGS)" CC=$(CC) 
>>>> ./configure --prefix=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf 
>>>> --with-build-cppflags="" --with-build-cflags="" --with-build-ldflags="" 
>>>> --with-build-libs="" && \
>>>>           $(MAKE) libs && \
>>>>           $(MAKE) install.libs )
>>>> 
>>>> The --with-build-* options do nothing, so two utilities must be compiled 
>>>> by hand.
>>>
>>> You need to pass the $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) there.
>> 
>> Sorry, I don't understand.  Where?  The target flags are the very
>> thing causing the problem for the build helper programs.
>
> In --with-build-*, I guess.  What do you hope to build with helper
> programs?  Mini-OS kernels?  That would indeed require much more
> invasive Makefile changes in ncurses.  I don't think you need that
> anyway.

Oh no, these helpers are run as part of the cross building process
itself, on the host system, not on the target.  In the end I found a
way to override the target flags for them by specifying
BUILD_CCFLAGS="" as a make argument.
-- 
Feri.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel