Xen devel - Apr 2009 - Pesky ''#define current'' in mini-os/sched.h

Hi,

I''m trying to port ncurses to mini-os, and hit an ugly snag:
xen-3.3.1/extras/mini-os/include/mini-os/sched.h says near the end:

#define current get_current()

which clashes with each field or variable named ''current''. 
Thus it
pollutes the global and field namespace real bad, and is very easy to
activate through including errno.h if HAVE_LIBC is defined.

What is the best way around?
-- 
Thanks,
Feri.

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

Ferenc Wagner, le Mon 27 Apr 2009 20:11:24 +0200, a écrit
:
> #define current get_current()
I guess we should probably just get rid of the current macro

Samuel

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

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> Ferenc Wagner, le Mon 27 Apr 2009 20:11:24 +0200, a écrit :
>> #define current get_current()
>
> I guess we should probably just get rid of the current macro
Simply removing it works in my case, but I guess there are cases when
it is needed, aren''t there?
-- 
Thanks,
Feri.

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

Ferenc Wagner, le Mon 27 Apr 2009 20:45:57 +0200, a écrit
:
> Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> > Ferenc Wagner, le Mon 27 Apr 2009 20:11:24 +0200, a écrit :
> >> #define current get_current()
> >
> > I guess we should probably just get rid of the current macro
> 
> Simply removing it works in my case, but I guess there are cases when
> it is needed, aren''t there?
Of course, everywhere it''s used inside minios.

Samuel

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

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> Ferenc Wagner, le Mon 27 Apr 2009 20:45:57 +0200, a écrit :
>> Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
>>> Ferenc Wagner, le Mon 27 Apr 2009 20:11:24 +0200, a écrit :
>>>> #define current get_current()
>>>
>>> I guess we should probably just get rid of the current macro
>> 
>> Simply removing it works in my case, but I guess there are cases when
>> it is needed, aren''t there?
>
> Of course, everywhere it''s used inside minios.
Ok.  Till then, may I ask for your help to integrate ncurses into
minios?  I''m not familiar with the build system.  Basically, I think I
got the ncurses library built for the minios target, but can''t use it
in my c stubdom yet, it get undefined references:

wferi@rs22:~/xen/xen-3.3.1/extras/mini-os$ ld -nostdlib
-L/home/wferi/xen/xen-3.3.1/stubdom/cross-root-i686/i686-xen-elf/lib
-L/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/lib -m elf_i386 -T
arch/x86/minios-x86_32.lds
/home/wferi/xen/xen-3.3.1/stubdom/mini-os-x86_32-c/mini-os.o -o
/home/wferi/xen/xen-3.3.1/stubdom/mini-os-x86_32-c/mini-os
/home/wferi/xen/xen-3.3.1/stubdom/mini-os-x86_32-c/mini-os.o: In function
`grub_ncurses_getxy'':
/home/wferi/xen/grub2/util/console.c:267: undefined reference to
`stdscr''
[...]

(Yes, I''m trying to build a PV-Grub2 for getting LVM support :)

Of course if I add -lncurses to the above command, I get lots of
undefined references to the libc functions from ncurses.
Sure it''s possible to find out, but it would be nice if you could
spare me a few cycles if you don''t mind.  At least I wouldn''t
waste
further effort banging my head against the wrong wall.
-- 
Thanks,
Feri.

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

On 27/04/2009 20:42, "Ferenc Wagner" <wferi@niif.hu> wrote:
>>> 
>>> Simply removing it works in my case, but I guess there are cases
when
>>> it is needed, aren''t there?
>> 
>> Of course, everywhere it''s used inside minios.
> 
> Ok.  Till then, may I ask for your help to integrate ncurses into
> minios?  I''m not familiar with the build system.  Basically, I
think I
> got the ncurses library built for the minios target, but can''t use
it
> in my c stubdom yet, it get undefined references:
The simplest fix would be to wrap the ''#define current'' in a
''#ifdef
__MINIOS__'' region. The cleaner fix would be to partition minios
headers
into private vs. public and not include the former from the latter, and keep
the latter namespace-clean.

 -- Keir



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

Keir Fraser, le Mon 27 Apr 2009 20:50:18 +0100, a écrit
:
> The simplest fix would be to wrap the ''#define current''
in a ''#ifdef
> __MINIOS__'' region.
There actually already is such wrapper.

Samuel

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

Ferenc Wagner, le Mon 27 Apr 2009 21:42:42 +0200, a écrit
:
> Of course if I add -lncurses to the above command, I get lots of
> undefined references to the libc functions from ncurses.
Which ones?  Adding -lncurses really is the correct way, just like is
done for libpci & libz for qemu-stubdom.

Samuel

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

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> Ferenc Wagner, le Mon 27 Apr 2009 21:42:42 +0200, a écrit :
>
>> Of course if I add -lncurses to the above command, I get lots of
>> undefined references to the libc functions from ncurses.
>
> Which ones?
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./base/lib_color.c:265:
undefined reference to `calloc''
etc.

No wonder, as the linker command originally had a single object
(mini-os.o), and if I put -lncurses before it, it wasn''t pulled in,
and if I put -lncurses after it, then every single libc function
became undefined.
> Adding -lncurses really is the correct way, just like is done for
> libpci & libz for qemu-stubdom.
Yes, but I tried the crazy way first, which was bound to fail.  Setting

LDLIBS := -L/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/lib -lncurses

in mini-os/Makefile got me further, but may still not be the correct
way.  I couldn''t track how it''s done for libpci & libz for
qemu-stubdom (ioemu?) yet.  This make magic is somewhat convoluted,
and I''m not too much into linker scripts et al.

So, where should I add it for proper operation?

Anyway, now I''m down to

/home/wferi/xen/xen-3.3.1/stubdom/mini-os-x86_32-c/mini-os.o: In function
`grub_memalign'':
/home/wferi/xen/grub2/util/misc.c:263: undefined reference to
`posix_memalign''
/home/wferi/xen/xen-3.3.1/stubdom/mini-os-x86_32-c/mini-os.o: In function
`find_root_device'':
/home/wferi/xen/grub2/util/getroot.c:215: undefined reference to
`lstat''
/home/wferi/xen/xen-3.3.1/stubdom/mini-os-x86_32-c/mini-os.o: In function
`tstp'':
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tty/lib_tstp.c:159:
undefined reference to `tcgetpgrp''
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tty/lib_tstp.c:159:
undefined reference to `getpgrp''
/home/wferi/xen/xen-3.3.1/stubdom/mini-os-x86_32-c/mini-os.o: In function
`baudrate'':
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/lib_baudrate.c:244:
undefined reference to `cfgetospeed''
/home/wferi/xen/xen-3.3.1/stubdom/mini-os-x86_32-c/mini-os.o: In function
`flushinp'':
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/lib_kernel.c:143:
undefined reference to `tcflush''
/home/wferi/xen/xen-3.3.1/stubdom/mini-os-x86_32-c/mini-os.o: In function
`_nc_vdisable'':
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/lib_kernel.c:67:
undefined reference to `fpathconf''
/home/wferi/xen/xen-3.3.1/stubdom/mini-os-x86_32-c/mini-os.o: In function
`_nc_access'':
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/access.c:112:
undefined reference to `access''
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/access.c:125:
undefined reference to `access''
make[1]: *** [/home/wferi/xen/xen-3.3.1/stubdom/mini-os-x86_32-c/mini-os] Error
1
make[1]: Leaving directory `/home/wferi/xen/xen-3.3.1/extras/mini-os''
make: *** [c-stubdom] Error 2

for grub-emu, which may be far or close, I don''t know yet...
-- 
Thank,
Feri.

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

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> Keir Fraser, le Mon 27 Apr 2009 20:50:18 +0100, a écrit :
>
>> The simplest fix would be to wrap the ''#define
current'' in a ''#ifdef
>> __MINIOS__'' region.
>
> There actually already is such wrapper.
Where?  Not in mini-os/sched.h.  There is an #ifdef HAVE_LIBC around
#include <mini-os/sched.h> in errno.h, though.
-- 
Feri.

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

Ferenc Wagner, le Mon 27 Apr 2009 22:32:06 +0200, a écrit
:
> Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> 
> > Keir Fraser, le Mon 27 Apr 2009 20:50:18 +0100, a écrit :
> >
> >> The simplest fix would be to wrap the ''#define
current'' in a ''#ifdef
> >> __MINIOS__'' region.
> >
> > There actually already is such wrapper.
> 
> Where?  Not in mini-os/sched.h.
Are we perhaps looking at different trees? I can see

#ifdef __INSIDE_MINIOS__

Samuel

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

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> Ferenc Wagner, le Mon 27 Apr 2009 22:32:06 +0200, a écrit :
>> Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
>> 
>>> Keir Fraser, le Mon 27 Apr 2009 20:50:18 +0100, a écrit :
>>>
>>>> The simplest fix would be to wrap the ''#define
current'' in a ''#ifdef
>>>> __MINIOS__'' region.
>>>
>>> There actually already is such wrapper.
>> 
>> Where?  Not in mini-os/sched.h.
>
> Are we perhaps looking at different trees? I can see
>
> #ifdef __INSIDE_MINIOS__
I''m working with xen-3.3.1, which is the latest stable, as far as I
know.  Maybe it''s already fixed in your development version.
-- 
Feri.

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

On 27/04/2009 21:47, "Ferenc Wagner" <wferi@niif.hu> wrote:
>> Are we perhaps looking at different trees? I can see
>> 
>> #ifdef __INSIDE_MINIOS__
> 
> I''m working with xen-3.3.1, which is the latest stable, as far as
I
> know.  Maybe it''s already fixed in your development version.
Yes, it''s fixed in xen-unstable but not in xen-3.3.

 -- Keir



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

Ferenc Wagner, le Mon 27 Apr 2009 22:29:02 +0200, a écrit
:
> Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> > Ferenc Wagner, le Mon 27 Apr 2009 21:42:42 +0200, a écrit :
> >
> >> Of course if I add -lncurses to the above command, I get lots of
> >> undefined references to the libc functions from ncurses.
> >
> > Which ones?
> 
>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./base/lib_color.c:265:
undefined reference to `calloc''
> etc.
> 
> No wonder, as the linker command originally had a single object
> (mini-os.o), and if I put -lncurses before it, it wasn''t pulled
in,
> and if I put -lncurses after it, then every single libc function
> became undefined.
Have you, like in the C example of stubdom/Makefile, propagated
TARGET_CPPFLAGS, TARGET_CFLAGS, and added a rule like is done for other
stubdom images in the "minios" paragraph of stubdom/Makefile?
> Yes, but I tried the crazy way first, which was bound to fail.  Setting
> 
> LDLIBS := -L/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/lib -lncurses
That''s not how it''s supposed to be done. See the Cross-zlib
paragraph
for instance: the cross-zlib target not only configures & builds libz,
but also installs it, the prefix being properly set during configuration
into the cross-chain directory.
> I couldn''t track how it''s done for libpci & libz for
qemu-stubdom
> (ioemu?) yet.
It''s all in stubdom/Makefile: they get installed within the
cross-root-$(GNU_TARGET_ARCH) hierarchy, where the linker finds it
thanks to the TARGET_LDFLAGS variable.
> This make magic is somewhat convoluted,
It''s no magic, it''s makefiles :)
> and I''m not too much into linker scripts et al.
You do not need to change any linker script.
> So, where should I add it for proper operation?
Just the same way as zlib & C stubdom examples.
> /home/wferi/xen/xen-3.3.1/stubdom/mini-os-x86_32-c/mini-os.o: In function
`grub_memalign'':
> /home/wferi/xen/grub2/util/misc.c:263: undefined reference to
`posix_memalign''
It should just be a matter of setting it as an alias for newlib''s
memalign, by adding a macro into newlib/libc/include/malloc.h for
instance.  Ideally it should be reported to newlib''s upstream actually.
> /home/wferi/xen/grub2/util/getroot.c:215: undefined reference to
`lstat''
>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tty/lib_tstp.c:159:
undefined reference to `tcgetpgrp''
>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tty/lib_tstp.c:159:
undefined reference to `getpgrp''
>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/lib_kernel.c:143:
undefined reference to `tcflush''
Should be fixed by the patch below.
>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/lib_baudrate.c:244:
undefined reference to `cfgetospeed''
I''m a bit surprised you actually got code using cfgetospeed compiled in
the miniOS environment.  It''s supposed to return something like B9600,
but that''s not defined by newlib!
>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/lib_kernel.c:67:
undefined reference to `fpathconf''
Same issue: how did you get that code to compile? _PC_VDISABLE is not
defined...  I believe you are not using the cross-chain flags.
>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/access.c:112:
undefined reference to `access''
>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/access.c:125:
undefined reference to `access''
Mmmm, the fsif protocol does not provide an access operation to
implement that properly. You could add a dummy implementation in
lib/sys.c that just open()/close() it and return proper error codes if
any and it should be fine for ncurses'' use cases.

Samuel




Add tcgetpgrp getpgrp tcflush and lstat dummy implementations.

Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

diff -r 9fdcd3ab84b7 extras/mini-os/lib/sys.c
--- a/extras/mini-os/lib/sys.c	Mon Apr 27 15:40:09 2009 +0100
+++ b/extras/mini-os/lib/sys.c	Mon Apr 27 23:05:01 2009 +0200
@@ -148,6 +148,16 @@
     return 1;
 }
 
+pid_t tcgetpgrp(int fd)
+{
+    return 1;
+}
+
+pid_t getpgrp(void)
+{
+    return 1;
+}
+
 char *getcwd(char *buf, size_t size)
 {
     snprintf(buf, size, "/");
@@ -365,6 +375,20 @@
     return -1;
 }
 
+int tcflush(int fd, int queue_selector)
+{
+    switch (files[fd].type) {
+        case FTYPE_CONSOLE:
+            /* Already flushed */
+            return 0;
+        default:
+            break;
+    }
+    printk("tcflush(%d): Bad descriptor\n", fd);
+    errno = EBADF;
+    return -1;
+}
+
 int close(int fd)
 {
     printk("close(%d)\n", fd);
@@ -473,6 +497,8 @@
 out:
     return ret;
 }
+/* We do not have symlinks */
+int lstat(const char *path, struct stat *buf)
__attribute__((alias("stat")));
 
 int fstat(int fd, struct stat *buf)
 {

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

Ferenc Wagner, le Mon 27 Apr 2009 22:47:54 +0200, a écrit
:
> Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> 
> > Ferenc Wagner, le Mon 27 Apr 2009 22:32:06 +0200, a écrit :
> >> Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> >> 
> >>> Keir Fraser, le Mon 27 Apr 2009 20:50:18 +0100, a écrit :
> >>>
> >>>> The simplest fix would be to wrap the ''#define
current'' in a ''#ifdef
> >>>> __MINIOS__'' region.
> >>>
> >>> There actually already is such wrapper.
> >> 
> >> Where?  Not in mini-os/sched.h.
> >
> > Are we perhaps looking at different trees? I can see
> >
> > #ifdef __INSIDE_MINIOS__
> 
> I''m working with xen-3.3.1, which is the latest stable, as far as
I
> know.  Maybe it''s already fixed in your development version.
Ok, yes it is.

Samuel

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

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> Have you, like in the C example of stubdom/Makefile, propagated
> TARGET_CPPFLAGS, TARGET_CFLAGS, and added a rule like is done for other
> stubdom images in the "minios" paragraph of stubdom/Makefile?
No, I had no idea how to start with this, I stole the various flags
from the output of make c-stubdom and configured ncurses with those.
> That''s not how it''s supposed to be done. See the
Cross-zlib paragraph
> for instance: the cross-zlib target not only configures & builds libz,
> but also installs it, the prefix being properly set during configuration
> into the cross-chain directory.
Oh yes, I copied that, but forgot the install step, because the build
itself was so tedious.
> Ferenc Wagner, le Mon 27 Apr 2009 22:29:02 +0200, a écrit :
>
>> I couldn''t track how it''s done for libpci & libz
for qemu-stubdom
>> (ioemu?) yet.
>
> It''s all in stubdom/Makefile: they get installed within the
> cross-root-$(GNU_TARGET_ARCH) hierarchy, where the linker finds it
> thanks to the TARGET_LDFLAGS variable.
>
>> This make magic is somewhat convoluted,
>
> It''s no magic, it''s makefiles :)
Ok, do I have to extend the # Links section as well?
>> So, where should I add it for proper operation?
>
> Just the same way as zlib & C stubdom examples.
I may be blind, but there''s no -l linker option in stubdom/Makefile.
>> /home/wferi/xen/xen-3.3.1/stubdom/mini-os-x86_32-c/mini-os.o: In
function `grub_memalign'':
>> /home/wferi/xen/grub2/util/misc.c:263: undefined reference to
`posix_memalign''
>
> It should just be a matter of setting it as an alias for newlib''s
> memalign, by adding a macro into newlib/libc/include/malloc.h for
> instance.  Ideally it should be reported to newlib''s upstream
actually.
Thanks for the tip.
>> /home/wferi/xen/grub2/util/getroot.c:215: undefined reference to
`lstat''
>>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tty/lib_tstp.c:159:
undefined reference to `tcgetpgrp''
>>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tty/lib_tstp.c:159:
undefined reference to `getpgrp''
>>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/lib_kernel.c:143:
undefined reference to `tcflush''
>
> Should be fixed by the patch below.
And thanks for the patch!  Will try once I get a correct build
infrastructure.
>>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/lib_baudrate.c:244:
undefined reference to `cfgetospeed''
>
> I''m a bit surprised you actually got code using cfgetospeed
compiled in
> the miniOS environment.  It''s supposed to return something like
B9600,
> but that''s not defined by newlib!
Yeah, I copied those defines from my libc headers.  Figured I won''t
need them after all, as the MiniOS console won''t care, so I can stub
them out later.  But wanted a proof of concept first of all.
>>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/lib_kernel.c:67:
undefined reference to `fpathconf''
>
> Same issue: how did you get that code to compile? _PC_VDISABLE is not
> defined...  I believe you are not using the cross-chain flags.
Hmm, I don''t remember hacking around this...
>>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/access.c:112:
undefined reference to `access''
>>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/access.c:125:
undefined reference to `access''
>
> Mmmm, the fsif protocol does not provide an access operation to
> implement that properly. You could add a dummy implementation in
> lib/sys.c that just open()/close() it and return proper error codes if
> any and it should be fine for ncurses'' use cases.
Thanks, that''s about what I expected.  Will do.

Until then, here are my notes from the yesterday session.  If you have
further comments, I''d be glad to hear them.

Thanks,
Feri.

---------------------------------------------------

1. wferi@rs22:~/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses$ gcc
-DHAVE_CONFIG_H -I../ncurses -I. -I. -I../include  -DNDEBUG
-I/home/wferi/xen/xen-3.3.1/stubdom/cross-root-i686/i686-xen-elf/include/ncurses
-isystem /home/wferi/xen/xen-3.3.1/stubdom/../extras/mini-os/include
-D__MINIOS__ -DHAVE_LIBC -isystem
/home/wferi/xen/xen-3.3.1/stubdom/../extras/mini-os/include/posix -isystem
/home/wferi/xen/xen-3.3.1/stubdom/../tools/xenstore  -isystem
/home/wferi/xen/xen-3.3.1/stubdom/../extras/mini-os/include/x86 -isystem
/home/wferi/xen/xen-3.3.1/stubdom/../extras/mini-os/include/x86/x86_32 -U
__linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem
/home/wferi/xen/xen-3.3.1/stubdom/../extras/mini-os/include/posix -isystem
/home/wferi/xen/xen-3.3.1/stubdom/cross-root-i686/i686-xen-elf/include -isystem
/usr/lib/gcc/i486-linux-gnu/4.3.2/include -isystem
/home/wferi/xen/xen-3.3.1/stubdom/lwip-x86_32/src/include -isystem
/home/wferi/xen/xen-3.3.1/stubdom/lwip-x86_32/src/include/ipv4 -I/ho
 me/wferi/xen/xen-3.3.1/stubdom/include  -O1 -fno-omit-frame-pointer
-fno-optimize-sibling-calls  -m32 -march=i686 -m32 -march=i686 -g
-fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement   -fno-stack-protector   --param
max-inline-insns-single=1200 -c ../objects/tty_update.c -o
../objects/tty_update.o

That is, both lwip -isystem pathes missed the -x86_32 bit (the original was the
result
of adapting the zlib cross-compilation stanza in stubdom/Makefile:

NCURSES_URL?=ftp://invisible-island.net/ncurses
NCURSES_VERSION=5.7

[...]

###############
# Cross-ncurses
###############

ncurses-$(NCURSES_VERSION).tar.gz:
        $(WGET) $(NCURSES_URL)/$@

ncurses-$(XEN_TARGET_ARCH): ncurses-$(NCURSES_VERSION).tar.gz
        tar xzf $<
        mv ncurses-$(NCURSES_VERSION) $@

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.

1b. Fix the two include pathes in stubdom/Makefile:

TARGET_CPPFLAGS += -isystem $(CURDIR)/lwip-x86_32/src/include
TARGET_CPPFLAGS += -isystem $(CURDIR)/lwip-x86_32/src/include/ipv4

(Probably helps after reconfiguration only.)

2. Some other file required renaming the local variable holding the current
screen from ''current'' to ''currrent'' (cca. 3
occurences) due to some strange
Xen include clash?!

3. ''columns'' in the above tty_update.c has a similar problem. 
Moving
#include <curses.priv.h> past #include <sys/select.h> solves this,
but still gives
../ncurses/./tty/tty_update.c:351: warning: implicit declaration of function
‘select’

4. Add to ../ncurses/./tinfo/lib_baudrate.c, above ''static struct speed
const speeds[] ='':

/* Copied from Linux'' /usr/include/bits/termios.h, Mini-OS has no
support for these */
#define  B0     0000000         /* hang up */
#define  B50    0000001
#define  B75    0000002
#define  B110   0000003
#define  B134   0000004
#define  B150   0000005
#define  B200   0000006
#define  B300   0000007
#define  B600   0000010
#define  B1200  0000011
#define  B1800  0000012
#define  B2400  0000013
#define  B4800  0000014
#define  B9600  0000015
#define  B19200 0000016
#define  B38400 0000017

5. Add to the head of ../ncurses/./tinfo/lib_kernel.c:

/* Copied from Linux'' /usr/include/bits/termios.h, Mini-OS has no
support for these */
#define VERASE 2
#define VKILL 3
#define TCIFLUSH        0

Maybe #undef TERMIOS would be better?  This still leaves:
../ncurses/./tinfo/lib_kernel.c:143: warning: implicit declaration of function
‘tcflush’

6. #include <curses.priv.h> problem in ../ncurses/./tty/lib_twait.c, too.

7. These alone get us a libncurses.a!

8. The ''form'' part still does not compile, because the field
''current'' in ../form/form.h
clashes with the #define current at
/home/wferi/xen/xen-3.3.1/stubdom/../extras/mini-os/include/mini-os/sched.h:51:1
This is the same problem as 2., but without an easy fix, as this
''current'' isn''t a
local variable.

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

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

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> Ferenc Wagner, le Mon 27 Apr 2009 22:29:02 +0200, a écrit :
>
>> LDLIBS := -L/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/lib
-lncurses
>
> That''s not how it''s supposed to be done. See the
Cross-zlib paragraph
> for instance: the cross-zlib target not only configures & builds libz,
> but also installs it, the prefix being properly set during configuration
> into the cross-chain directory.
Now I have ncurses installed into cross-root.  Suppose I want to use
it from c-stubdom.  #include <ncurses/curses.h> works without any
further modification, but where should I put -lncurses?  The best I
could come up with is APP_LDLIBS in extras/mini-os/Makefile...
>> /home/wferi/xen/xen-3.3.1/stubdom/mini-os-x86_32-c/mini-os.o: In
function `grub_memalign'':
>> /home/wferi/xen/grub2/util/misc.c:263: undefined reference to
`posix_memalign''
>
> It should just be a matter of setting it as an alias for newlib''s
> memalign, by adding a macro into newlib/libc/include/malloc.h for
> instance.  Ideally it should be reported to newlib''s upstream
actually.
Seems good.
> Should be fixed by the patch below.
Works as advertised, thanks!
>>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/lib_baudrate.c:244:
undefined reference to `cfgetospeed''
>
> I''m a bit surprised you actually got code using cfgetospeed
compiled in
> the miniOS environment.  It''s supposed to return something like
B9600,
> but that''s not defined by newlib!
I''ll stub this to always return B38400 and define those constants.  Do
you think it matters the least?
>>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/lib_kernel.c:67:
undefined reference to `fpathconf''
>
> Same issue: how did you get that code to compile? _PC_VDISABLE is not
> defined...  I believe you are not using the cross-chain flags.
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?
>>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/access.c:112:
undefined reference to `access''
>>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/access.c:125:
undefined reference to `access''
>
> Mmmm, the fsif protocol does not provide an access operation to
> implement that properly. You could add a dummy implementation in
> lib/sys.c that just open()/close() it and return proper error codes if
> any and it should be fine for ncurses'' use cases.
I stubbed this last one, and now I can compile the ncurses example at
http://www.captain.at/howto-curses-example.php as a c-stubdom; too bad
it does not work:

Error opening terminal: unknown.

Now let''s try to hardwire the terminal type to xterm or similar...
-- 
Cheers,
Feri.

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

Ferenc Wagner, le Tue 28 Apr 2009 19:57:07 +0200, a écrit
:
> > I''m a bit surprised you actually got code using cfgetospeed
compiled in
> > the miniOS environment.  It''s supposed to return something
like B9600,
> > but that''s not defined by newlib!
> 
> I''ll stub this to always return B38400 and define those constants.
Do
> you think it matters the least?
I doesn''t.
> >>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/lib_kernel.c:67:
undefined reference to `fpathconf''
> >
> > Same issue: how did you get that code to compile? _PC_VDISABLE is not
> > defined...  I believe you are not using the cross-chain flags.
> 
> newlib-1.16.0/newlib/libc/include/sys/unistd.h defines _PC_VDISABLE.
Oh, right it''s not defined in the linux/ part.
> 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?
That one should be fine indeed.
> >>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/access.c:112:
undefined reference to `access''
> >>
/home/wferi/xen/xen-3.3.1/stubdom/ncurses-x86_32/ncurses/../ncurses/./tinfo/access.c:125:
undefined reference to `access''
> >
> > Mmmm, the fsif protocol does not provide an access operation to
> > implement that properly. You could add a dummy implementation in
> > lib/sys.c that just open()/close() it and return proper error codes if
> > any and it should be fine for ncurses'' use cases.
> 
> I stubbed this last one, and now I can compile the ncurses example at
> http://www.captain.at/howto-curses-example.php as a c-stubdom; too bad
> it does not work:
> 
> Error opening terminal: unknown.
What do you mean by "stubbing"?  An implementation just always
returning
an error?
> 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.

Now, I''m wondering about the ncurses requirement: is grub2 really
using it for the bootloader, not just for the userland tool?  Note for
instance that in the case of grub1, I took care of _not_ compiling
grub/asmstub.c which is the source for the userland grub, not the
bootloader.

Samuel

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

Ferenc Wagner, le Tue 28 Apr 2009 12:12:54 +0200, a écrit
:
> Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> > Have you, like in the C example of stubdom/Makefile, propagated
> > TARGET_CPPFLAGS, TARGET_CFLAGS, and added a rule like is done for
other
> > stubdom images in the "minios" paragraph of
stubdom/Makefile?
> 
> No, I had no idea how to start with this, I stole the various flags
> from the output of make c-stubdom and configured ncurses with those.
Errrr, that''s an odd way. ncurses is a library, so stole things from a
library, see the cross-zlib part for instance.  No need to look at
c-stubdom (which is only about the main application, not a library).
> > Ferenc Wagner, le Mon 27 Apr 2009 22:29:02 +0200, a écrit :
> >
> >> I couldn''t track how it''s done for libpci &
libz for qemu-stubdom
> >> (ioemu?) yet.
> >
> > It''s all in stubdom/Makefile: they get installed within the
> > cross-root-$(GNU_TARGET_ARCH) hierarchy, where the linker finds it
> > thanks to the TARGET_LDFLAGS variable.
> >
> >> This make magic is somewhat convoluted,
> >
> > It''s no magic, it''s makefiles :)
> 
> 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.
> >> So, where should I add it for proper operation?
> >
> > Just the same way as zlib & C stubdom examples.
> 
> 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.
> 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.

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...
> 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.

Samuel

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

Ferenc Wagner <wferi@niif.hu> writes:
> Error opening terminal: unknown.
>
> Now let''s try to hardwire the terminal type to xterm or similar...
Yeah, calling setenv("TERM","xterm",1) before initialization
resulted
in a working ncurses stub domain!  Patches against Xen-3.3.1 attached.

 * One needs to apply xen_ncurses.patch only, that references the
 other two (so tune the paths).

 * fpathconf() is stubbed in main.c, because I don''t understand the
 issue yet.

 * access() is also blatantly stubbed, as it''s pointless in stub
 domains anyway.

 * Most other changes are debatable as well, but they''re quite small
 and should be even smaller in the development version, where some
 issues are already fixed.

 * Example from http://www.captain.at/howto-curses-example.php.

I think something like this (but done right) would be useful in the
official packages as well.

Comments welcome!
-- 
Thanks,
Feri.




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

Ferenc Wagner, le Tue 28 Apr 2009 20:22:11 +0200, a écrit
:
>  * fpathconf() is stubbed in main.c, because I don''t understand
the
>  issue yet.
Just use the implementation from the linux/ part of newlib, it should be
fine.
>  * access() is also blatantly stubbed, as it''s pointless in stub
>  domains anyway.
No it''s not.  It''s just a matter of adding the interface to
fsio.
Trying to open/close the file and returning appropriate errors should
already be enough to test the R_OK and W_OK cases, which are what
ncurses use in addition to X_OK which we could consider as always
successful for now.
>  * Most other changes are debatable as well, but they''re quite
small
>  and should be even smaller in the development version, where some
>  issues are already fixed.
Yes, please rebase to that.

Content-Description: Master patch against Xen-3.3.1
> diff -ru xen-3.3.1.orig/extras/mini-os/lib/sys.c
xen-3.3.1/extras/mini-os/lib/sys.c
> --- xen-3.3.1.orig/extras/mini-os/lib/sys.c	2009-01-05 12:26:58.000000000
+0100
> +++ xen-3.3.1/extras/mini-os/lib/sys.c	2009-04-28 19:43:43.151850562 +0200
> @@ -147,6 +147,16 @@
>      return 1;
>  }
>  
> +pid_t tcgetpgrp(int fd)
> +{
> +    return 1;
> +}
> +
> +pid_t getpgrp(void)
> +{
> +    return 1;
> +}
> +
>  char *getcwd(char *buf, size_t size)
>  {
>      snprintf(buf, size, "/");
Do not forget to put the
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
To keep credits (as well as blame) properly assigned.
> diff -ru xen-3.3.1.orig/extras/mini-os/Makefile
xen-3.3.1/extras/mini-os/Makefile
> --- xen-3.3.1.orig/extras/mini-os/Makefile	2009-01-05 12:26:58.000000000
+0100
> +++ xen-3.3.1/extras/mini-os/Makefile	2009-04-28 19:43:43.151850562 +0200
> @@ -20,7 +20,7 @@
>  
>  # Define some default flags for linking.
>  LDLIBS := 
> -APP_LDLIBS := 
> +APP_LDLIBS := -lncurses
>  LDARCHLIB := -L$(OBJ_DIR)/$(TARGET_ARCH_DIR) -l$(ARCH_LIB_NAME)
>  LDFLAGS_FINAL := -T $(TARGET_ARCH_DIR)/minios-$(XEN_TARGET_ARCH).lds
It shouldn''t be there, but in your c-stubdom Makefile, just like
regular
applications do.
> @@ -85,6 +87,7 @@
>  newlib-$(NEWLIB_VERSION): newlib-$(NEWLIB_VERSION).tar.gz
>  	tar xzf $<
>  	patch -d $@ -p0 < newlib.patch
> +	patch -d $@ -p0 < ~/xen/newlib_memalign.patch
Just fold it into newlib.patch, no need to separate them.

Samuel

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

Hi Samuel,

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

Samuel Thibault <samuel.thibault@ens-lyon.org> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

Ferenc Wagner, le Tue 28 Apr 2009 20:47:41 +0200, a écrit
:
> Samuel Thibault <samuel.thibault@ens-lyon.org> 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"?

_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.
Just take that implementation and it will get compiled in.
> >> 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.
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.
> > 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...
> >> 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.
> >>
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.
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.

Samuel

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

Samuel Thibault, le Tue 28 Apr 2009 20:59:08 +0200, a écrit
:
> > >> 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.
> 
> 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.
(And put it in the ncurses code. Generally speaking minios _is_ able to
access files, via fsif).

Samuel

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

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> Ferenc Wagner, le Tue 28 Apr 2009 20:47:41 +0200, a écrit :
>> Samuel Thibault <samuel.thibault@ens-lyon.org> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> Ferenc Wagner, le Tue 28 Apr 2009 20:22:11 +0200, a écrit :
>
>>  * fpathconf() is stubbed in main.c, because I don''t
understand the
>>  issue yet.
>
> Just use the implementation from the linux/ part of newlib, it should be
> fine.
As noted in my other reply, it isn''t clear to me how I could use the
linux/ part of newlib, sorry.
>>  * access() is also blatantly stubbed, as it''s pointless in
stub
>>  domains anyway.
>
> No it''s not.  It''s just a matter of adding the interface
to fsio.
I meant that it makes a distinction on real vs effective UID/GID,
which isn''t an issue in the single-user stubdom environment.
Otherwise, I wouldn''t do anything but opened races...
> Trying to open/close the file and returning appropriate errors should
> already be enough to test the R_OK and W_OK cases,
Only if euid=ruid, which is always the case in stubdom, isn''t it?  But
then trying the operation itself provides the exact same diagnostics.
This is what I mean by "pointless".
> which are what ncurses use in addition to X_OK which we could
> consider as always successful for now.
Yes, we could approximate the functionality.  I don''t know what
ncurses uses it for, but we''ll see.
>>  * Most other changes are debatable as well, but they''re quite
small
>>  and should be even smaller in the development version, where some
>>  issues are already fixed.
>
> Yes, please rebase to that.
Will do if this stuff turns out to be useful after all.
> Do not forget to put the
> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> To keep credits (as well as blame) properly assigned.
Sure, I didn''t mean this as a patch submission.  As your changes are
generally useful, I expected that you submit them anyway, and they
disappear from my diff.
>> diff -ru xen-3.3.1.orig/extras/mini-os/Makefile
xen-3.3.1/extras/mini-os/Makefile
>> --- xen-3.3.1.orig/extras/mini-os/Makefile	2009-01-05
12:26:58.000000000 +0100
>> +++ xen-3.3.1/extras/mini-os/Makefile	2009-04-28 19:43:43.151850562
+0200
>> @@ -20,7 +20,7 @@
>>  
>>  # Define some default flags for linking.
>>  LDLIBS := 
>> -APP_LDLIBS := 
>> +APP_LDLIBS := -lncurses
>>  LDARCHLIB := -L$(OBJ_DIR)/$(TARGET_ARCH_DIR) -l$(ARCH_LIB_NAME)
>>  LDFLAGS_FINAL := -T $(TARGET_ARCH_DIR)/minios-$(XEN_TARGET_ARCH).lds
>
> It shouldn''t be there, but in your c-stubdom Makefile, just like
regular
> applications do.
My problem is that the c-stubdom Makefile does not link, but creates
an archive instead, so I can''t add linker options there.
>> @@ -85,6 +87,7 @@
>>  newlib-$(NEWLIB_VERSION): newlib-$(NEWLIB_VERSION).tar.gz
>>  	tar xzf $<
>>  	patch -d $@ -p0 < newlib.patch
>> +	patch -d $@ -p0 < ~/xen/newlib_memalign.patch
>
> Just fold it into newlib.patch, no need to separate them.
Grub2 fell over on this, btw.  In util/misc.c:

/* Include malloc.h, only if memalign is available. It is known that
   memalign is declared in malloc.h in all systems, if present.  */
#ifdef HAVE_MEMALIGN
# include <malloc.h>
#endif

[...]

void *
grub_memalign (grub_size_t align, grub_size_t size)
{
  void *p;

#if defined(HAVE_POSIX_MEMALIGN)
  if (posix_memalign (&p, align, size) != 0)
    p = 0;
#elif defined(HAVE_MEMALIGN)
  p = memalign (align, size);
#else
  (void) align;
  (void) size;
  grub_util_error ("grub_memalign is not supported");
#endif
  
  if (! p)
    grub_util_error ("out of memory");
  
  return p;
}

which shows that memalign() and posix_memalign() have a different
number of arguments, so #define posix_memalign memalign can''t be
right.
-- 
Feri.

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

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> Samuel Thibault, le Tue 28 Apr 2009 20:59:08 +0200, a écrit :
>
>>>>> 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.
>> 
>> 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.
>
> (And put it in the ncurses code. Generally speaking minios _is_ able to
> access files, via fsif).
So why deprive ncurses of accessing files for ever?  Eventually it
could as well read the terminfo database from the host.  Btw. it tries
to do so by invoking a stat() call, and then segfaults the stubdom.
So there''s some problem left here, more serious than access().
-- 
Feri.

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

Ferenc Wagner, le Tue 28 Apr 2009 21:43:17 +0200, a écrit
:
> > 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?
Yep.
> >>> 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.
Err, does grub2 compiles ncurses into the bootloader too?
> 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.
Oh right, sorry.  The final link is not done there but by the minios
paragraph of stubdom/Makefile.  You can either set APP_LDLIBS to
-lncurses there, to override the empty default of mini-os/Makefile, or
add -lncurses to APP_LDLIBS in the ifeq($libc),y) section along others.

Samuel

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

Ferenc Wagner, le Tue 28 Apr 2009 22:02:03 +0200, a écrit
:
> Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> 
> > Samuel Thibault, le Tue 28 Apr 2009 20:59:08 +0200, a écrit :
> >
> >>>>> 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.
> >> 
> >> 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.
> >
> > (And put it in the ncurses code. Generally speaking minios _is_ able
to
> > access files, via fsif).
> 
> So why deprive ncurses of accessing files for ever?
That''s why I said to put it in the ncurses code, as you said you
enabled
an internal database.
> Eventually it could as well read the terminfo database from the host.
> Btw. it tries to do so by invoking a stat() call, and then segfaults
> the stubdom.  So there''s some problem left here, more serious than
> access().
Right, I''m not sure we really want to have a stubdom do this.

Samuel

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

Ferenc Wagner, le Tue 28 Apr 2009 21:56:07 +0200, a écrit
:
> >>  * access() is also blatantly stubbed, as it''s pointless
in stub
> >>  domains anyway.
> >
> > No it''s not.  It''s just a matter of adding the
interface to fsio.
> 
> I meant that it makes a distinction on real vs effective UID/GID,
> which isn''t an issue in the single-user stubdom environment.
> Otherwise, I wouldn''t do anything but opened races...
> 
> > Trying to open/close the file and returning appropriate errors should
> > already be enough to test the R_OK and W_OK cases,
> 
> Only if euid=ruid, which is always the case in stubdom, isn''t it?
Yes.
> But then trying the operation itself provides the exact same
> diagnostics.  This is what I mean by "pointless".
Ok, but applications could still be upset to see access() work and not
open(), or vice-versa.
> #if defined(HAVE_POSIX_MEMALIGN)
>   if (posix_memalign (&p, align, size) != 0)
>     p = 0;
> #elif defined(HAVE_MEMALIGN)
>   p = memalign (align, size);
Errr, so grub2 doesn''t unconditionally use posix_memalign.  How did
grub2 detect HAVE_POSIX_MEMALIGN?  Adding posix_memalign as a proper
function shouldn''t be hard, though (and could be submitted upstream).

Samuel

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

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> Ferenc Wagner, le Tue 28 Apr 2009 21:56:07 +0200, a écrit :
>
>> But then trying the operation itself provides the exact same
>> diagnostics.  This is what I mean by "pointless".
>
> Ok, but applications could still be upset to see access() work and not
> open(), or vice-versa.
Sure, but then they are buggy.  No one should assume that nothing
changes in the time slice between access() and open() for example.
>> #if defined(HAVE_POSIX_MEMALIGN)
>>   if (posix_memalign (&p, align, size) != 0)
>>     p = 0;
>> #elif defined(HAVE_MEMALIGN)
>>   p = memalign (align, size);
>
> Errr, so grub2 doesn''t unconditionally use posix_memalign.  How
did
> grub2 detect HAVE_POSIX_MEMALIGN?
By autoconf:
AC_CHECK_FUNCS(posix_memalign memalign asprintf)
> Adding posix_memalign as a proper function shouldn''t be hard,
though
> (and could be submitted upstream).
If you say so...  It''s actually the first time I met the memalign
family.
>>> 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?
>
> Yep.
Horrors!
>>>>> 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.
>
> Err, does grub2 compiles ncurses into the bootloader too?
No, it does not.
>> 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.
>
> Oh right, sorry.  The final link is not done there but by the minios
> paragraph of stubdom/Makefile.  You can either set APP_LDLIBS to
> -lncurses there, to override the empty default of mini-os/Makefile, or
> add -lncurses to APP_LDLIBS in the ifeq($libc),y) section along others.
This is what I did in the POC.
> Ferenc Wagner, le Tue 28 Apr 2009 22:02:03 +0200, a écrit :
>
>> Eventually it could as well read the terminfo database from the host.
>> Btw. it tries to do so by invoking a stat() call, and then segfaults
>> the stubdom.  So there''s some problem left here, more serious
than
>> access().
>
> Right, I''m not sure we really want to have a stubdom do this.
Do you mean accessing the host filesystem?  I agree that shouldn''t be
made necessary, as stubdoms are a security measure in part.

Huh, I''m getting out of steam for today, and not sure I will be able
to work on this tomorrow.  Now comes interfacing grub2''s host disk
access code with blkfront, which wouldn''t be hard if blkfront
didn''t
require aligned buffers... :/
-- 
Thanks for today''s help, again!
Cheers,
Feri.

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

Ferenc Wagner, le Tue 28 Apr 2009 22:46:19 +0200, a écrit
:
> Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> > Ferenc Wagner, le Tue 28 Apr 2009 21:56:07 +0200, a écrit :
> >
> >> But then trying the operation itself provides the exact same
> >> diagnostics.  This is what I mean by "pointless".
> >
> > Ok, but applications could still be upset to see access() work and not
> > open(), or vice-versa.
> 
> Sure, but then they are buggy.
So be they.  We unfortunately can''t change all of them just by will.
> >> #if defined(HAVE_POSIX_MEMALIGN)
> >>   if (posix_memalign (&p, align, size) != 0)
> >>     p = 0;
> >> #elif defined(HAVE_MEMALIGN)
> >>   p = memalign (align, size);
> >
> > Errr, so grub2 doesn''t unconditionally use posix_memalign. 
How did
> > grub2 detect HAVE_POSIX_MEMALIGN?
> 
> By autoconf:
> AC_CHECK_FUNCS(posix_memalign memalign asprintf)
Mmmmm, and I guess it''s linking against the host OS, not the stubdom
OS,
grmbl.
> > Oh right, sorry.  The final link is not done there but by the minios
> > paragraph of stubdom/Makefile.  You can either set APP_LDLIBS to
> > -lncurses there, to override the empty default of mini-os/Makefile, or
> > add -lncurses to APP_LDLIBS in the ifeq($libc),y) section along
others.
> 
> This is what I did in the POC.
Err, in your patch it wasn''t in the ifeq section but the empty
declaration.
> > Ferenc Wagner, le Tue 28 Apr 2009 22:02:03 +0200, a écrit :
> >
> >> Eventually it could as well read the terminfo database from the
host.
> >> Btw. it tries to do so by invoking a stat() call, and then
segfaults
> >> the stubdom.  So there''s some problem left here, more
serious than
> >> access().
> >
> > Right, I''m not sure we really want to have a stubdom do this.
> 
> Do you mean accessing the host filesystem?  I agree that shouldn''t
be
> made necessary, as stubdoms are a security measure in part.
Yes.

Samuel

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

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> Ferenc Wagner, le Tue 28 Apr 2009 22:46:19 +0200, a écrit :
>> Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
>>> Ferenc Wagner, le Tue 28 Apr 2009 21:56:07 +0200, a écrit :
>>>
>>>> But then trying the operation itself provides the exact same
>>>> diagnostics.  This is what I mean by "pointless".
>>>
>>> Ok, but applications could still be upset to see access() work and
not
>>> open(), or vice-versa.
>> 
>> Sure, but then they are buggy.
>
> So be they.  We unfortunately can''t change all of them just by
will.
I tried to imply there shouldn''t be that many of them.  Maybe none...
Well, at least not too many which could be usefully run in a stubdom.
>>>> #if defined(HAVE_POSIX_MEMALIGN)
>>>>   if (posix_memalign (&p, align, size) != 0)
>>>>     p = 0;
>>>> #elif defined(HAVE_MEMALIGN)
>>>>   p = memalign (align, size);
>>>
>>> Errr, so grub2 doesn''t unconditionally use posix_memalign.
How did
>>> grub2 detect HAVE_POSIX_MEMALIGN?
>> 
>> By autoconf:
>> AC_CHECK_FUNCS(posix_memalign memalign asprintf)
>
> Mmmmm, and I guess it''s linking against the host OS, not the
stubdom OS,
> grmbl.
Ugh, that can be.  One can''t pass LDFLAGS to configure, as then:

checking whether the C compiler works... configure: error: cannot run C compiled
programs.

Cross compilation should be made more explicit somehow.
>>> Oh right, sorry.  The final link is not done there but by the
minios
>>> paragraph of stubdom/Makefile.  You can either set APP_LDLIBS to
>>> -lncurses there, to override the empty default of mini-os/Makefile,
or
>>> add -lncurses to APP_LDLIBS in the ifeq($libc),y) section along
others.
>> 
>> This is what I did in the POC.
>
> Err, in your patch it wasn''t in the ifeq section but the empty
> declaration.
Yes, I read the above as allowing that.  But I''ll move it.
-- 
Thanks,
Feri.

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

Ferenc Wagner, le Tue 28 Apr 2009 23:24:24 +0200, a écrit
:
> >> By autoconf:
> >> AC_CHECK_FUNCS(posix_memalign memalign asprintf)
> >
> > Mmmmm, and I guess it''s linking against the host OS, not the
stubdom OS,
> > grmbl.
> 
> Ugh, that can be.  One can''t pass LDFLAGS to configure, as then:
> 
> checking whether the C compiler works... configure: error: cannot run C
compiled programs.
Yes since it''d have to not only link libc.a but also the minios kernel.

Samuel

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

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> Ferenc Wagner, le Tue 28 Apr 2009 20:22:11 +0200, a écrit :
>>  * fpathconf() is stubbed in main.c, because I don''t
understand the
>>  issue yet.
>
> Just use the implementation from the linux/ part of newlib, it should be
> fine.
After respinning this stuff against unstable, I couldn''t find and easy
way to compile fpathconf() from the linux part of newlib (lots of
undefined symbols everywhere), so this didn''t change.  Anyway, if
it''s
linux specific, it should be stubdom specific as well, as I understand it.

A dummy access() is much easier, it''s probably never invoked, so I
didn''t care for now.
>>  * Most other changes are debatable as well, but they''re quite
small
>>  and should be even smaller in the development version, where some
>>  issues are already fixed.
>
> Yes, please rebase to that.
Please find the exported ncurses patch queue attached.  There are
still header problems, but these are ncurses ones: columns is #defined
in ncurses-x86_32/include/term.h, which breaks line 590 in
stubdom/include/xen/xen.h, if curses.priv.h is #included before
sys/select.h.  There were two occurences of this.  Otherwise, the
included example works pretty good.

Cheers,
Feri.



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

Ferenc Wagner, le Wed 13 May 2009 21:07:27 +0200, a écrit
:
> Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> > Ferenc Wagner, le Tue 28 Apr 2009 20:22:11 +0200, a écrit :
> >>  * fpathconf() is stubbed in main.c, because I don''t
understand the
> >>  issue yet.
> >
> > Just use the implementation from the linux/ part of newlib, it should
be
> > fine.
> 
> After respinning this stuff against unstable, I couldn''t find and
easy
> way to compile fpathconf() from the linux part of newlib
Err, I was probably not clear: I meant to just copy the code, not try to
do Makefile contorsions to manage to compile linux files.
> Anyway, if it''s linux specific, it should be stubdom specific as
well,
> as I understand it.
Actually the linux implementation is not.
> columns is #defined
> in ncurses-x86_32/include/term.h, which breaks line 590 in
> stubdom/include/xen/xen.h,
Damn.  ncurses sucks :)
The inversion of headers should be not so ugly, though.

Samuel

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

Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> Ferenc Wagner, le Wed 13 May 2009 21:07:27 +0200, a écrit :
>> Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
>>> Ferenc Wagner, le Tue 28 Apr 2009 20:22:11 +0200, a écrit :
>>>>  * fpathconf() is stubbed in main.c, because I don''t
understand the
>>>>  issue yet.
>>>
>>> Just use the implementation from the linux/ part of newlib, it
should be
>>> fine.
>> 
>> After respinning this stuff against unstable, I couldn''t find
and easy
>> way to compile fpathconf() from the linux part of newlib
>
> Err, I was probably not clear: I meant to just copy the code, not try to
> do Makefile contorsions to manage to compile linux files.
I didn''t try that.  I copied fpathconf.c into stubdom/c	and tried to
compile it alongside main.c.  It wanted	to #include everything in the
world and more,	so I called it a day.
>> Anyway, if it''s linux specific, it should be stubdom specific
as well,
>> as I understand it.
>
> Actually the linux implementation is not.
Fine, then.
>> columns is #defined
>> in ncurses-x86_32/include/term.h, which breaks line 590 in
>> stubdom/include/xen/xen.h,
>
> Damn.  ncurses sucks :)
> The inversion of headers should be not so ugly, though.
I feel it isn''t as it is, don''t you think?  Two simple changes
in two
files, to get the static library compiled, as the patches show.

Anyway, maybe this stuff loses relevance.  I asked the Grub
developers, and they were more interested in porting Grub natively to
Xen PV than piggybacking Mini-OS.  But I couldn''t find the Xen ABI
documentation (or whatever it''s called).  blkif-drivers-explained.txt
sounds somewhat aged.  Can you recommend something definitive?  Also,
the roadmap suggests that some changes are expected.  That would mean
4 different new architectures for Grub (32 vs 64 bit and current vs
new ABI)...
-- 
Feri.

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

Ferenc Wagner, le Thu 14 May 2009 13:36:36 +0200, a écrit
:
> Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> > Err, I was probably not clear: I meant to just copy the code, not try
to
> > do Makefile contorsions to manage to compile linux files.
> 
> I didn''t try that.  I copied fpathconf.c into stubdom/c	and tried
to
> compile it alongside main.c.  It wanted	to #include everything in the
> world and more,	so I called it a day.
I didn''t mean the whole file, just the code that you need, 

    case _PC_VDISABLE:
#ifdef>-_POSIX_VDISABLE
      return _POSIX_VDISABLE;
#else
      return -1;
#endif

and the fd<0 check case and default:
> >> Anyway, if it''s linux specific, it should be stubdom
specific as well,
> >> as I understand it.
> >
> > Actually the linux implementation is not.
> 
> Fine, then.
I mean, the few lines above.
> >> columns is #defined
> >> in ncurses-x86_32/include/term.h, which breaks line 590 in
> >> stubdom/include/xen/xen.h,
> >
> > Damn.  ncurses sucks :)
> > The inversion of headers should be not so ugly, though.
> 
> I feel it isn''t as it is, don''t you think?  Two simple
changes in two
> files, to get the static library compiled, as the patches show.
> 
> Anyway, maybe this stuff loses relevance.  I asked the Grub
> developers, and they were more interested in porting Grub natively to
> Xen PV than piggybacking Mini-OS.  But I couldn''t find the Xen ABI
> documentation (or whatever it''s called).
It''s all in docs/, interface.tex notably, and xen/include/public/
> Also, the roadmap suggests that some changes are expected.
Which roadmap, where?

Samuel

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