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

[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
http://grub.enbug.org/FranklinPiat/grub-emu.manpage
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)
>> $(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.

> 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...
-- 
Thanks,
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®.