[Xen-devel] Re: POC: ncurses in stubdom

[Ferenc Wagner <wferi@xxxxxxx>]

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
>>  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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel