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/
Home Products Support Community News


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

Hi Samuel,

I've just sent the summary mail before reading yours...

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 mean by "stubbing"?  An implementation just always
> returning an error?

Or rather success, in this case.  But yes.

>> Now let's try to hardwire the terminal type to xterm or similar...
> Note that for that to eventually work you need to give your stubdomain
> access to the terminfo database via fsif.

For now I configured out database access and compiled in some fallbacks.

> 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.  That may or may not work out.  All I know is
Failure was and is an option. :)

>> Ok, do I have to extend the # Links section as well?
> You need to add a cross-ncurses dependency, but the rest is only for
> libxc.

I wonder how I got it right...

>> 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.  Looks like I
really had better starting with the development tree, but I read
stubdom has problems there...

>> NCURSES_STAMPFILE=$(CROSS_ROOT)/$(GNU_TARGET_ARCH)-xen-elf/lib/libncurses.a
>> .PHONY: cross-ncurses
>> cross-ncurses: $(NCURSES_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.

> I'm actually feared by all your terminal additions.  These will probably
> never be implemented in mini-os.  They can sure be stubbed, but the
> application will probably just not work properly.  Remember that the Xen
> console can be attached/detached/reattached from a lot of various kinds
> of terminals...

Yes, the terminal type should be propagated (and changed on the fly)
in mini-os, which is infeasible.  Either one has to stick to some
common subset or use this in short-lived stub domains only.  For
example with a boot loader. :)

>> 9. Actually, deleting #define current get_current() from
>> extras/mini-os/include/mini-os/sched.h made libncurses++.a build,
>> but broke make c-stubdom...  According to Keir Fraser, the simplest
>> fix is:
>> #ifdef __MINIOS__
>> #define current get_current()
>> #endif
> Use the same fix as in the unstable tree.

Yes, it didn't work, __MINIOS__ is defined all the time.  I worked
around in ncurses instead for now.

So let's see how grub-emu likes this environment...

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>