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: POC: ncurses in stubdom

Samuel Thibault <samuel.thibault@xxxxxxxxxxxx> 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

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

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!

Xen-devel mailing list