[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.