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 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@xxxxxxxxxxxx>
> 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
> 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.  */
# include <malloc.h>


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

  if (posix_memalign (&p, align, size) != 0)
    p = 0;
#elif defined(HAVE_MEMALIGN)
  p = memalign (align, size);
  (void) align;
  (void) size;
  grub_util_error ("grub_memalign is not supported");
  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

Xen-devel mailing list