similar to: Re: Xen Roadmap proposal and Mini-OS C library

I sent this patch directly to Gregor, and neglected to CC this list. Sorry about that. I''d like to make it so that there is no need to modify any Mini-OS source files when extending it with an application. All that is required is a change to Makefile, and a small change to kernel.c, printf.c, and string.c. I have enclosed the patch. With this patch, one could write an application in a

Please patch Mini-OS so that it uses stddef.h to define size_t and NULL. This problem fixes errors that occur when linking Mini-OS with ANSI standard code that uses stddef.h. John diff -ur oxen-3.0-testing/extras/mini-os/include/lib.h nxen-3.0-testing/extras/mini-os/include/lib.h --- oxen-3.0-testing/extras/mini-os/include/lib.h 2006-04-14 22:21:55.000000000 -0400 +++

I am seeing a strange issue while running Mini-OS on the changeset 9906:a95e677073c1. This is on both i386 and x86_64. The only difference being on i386 if I stop printing to the console, this issue is not manifested. But with x86_64 it happens all the time. Bringing up Mini-OS for the first time causes xm to hang on certain commands like "list, destroy". Other commands like

For a while I''ve been intending to provide a better environment for PV baremetal guests. The current arrangements, based on newlib, take quite a bit of porting for many programs. My plan is to take the FreeBSD libc, and write a set of functions implementing the "system calls" in terms of facilities provided by the Xen PV environment, frontend drivers, etc. As part of this I

Hi folks I have some tasks for you on the Xen packages: * copyright file I doubt that this is in any way current. * pvgrub This contains several parts which needs to be statically linked together: - minios, libxenctrl, libxenguest, libxenstore, all built out of the xen tree, - patched grub, - patched newlib and - a libz. - ioemu/dom0 userspace The upstream build uses a clone

Hello user-list, Here is my pb : I have a brand new debian Etch with all updates installed on a DELL PE SC430 with a Pentium D 930 (3Ghz, Intel-VT, EMT64) I''ve downloaded xen-3.3 and tried to install with /*"The Perfect Xen 3.1.0 Setup For Debian Etch" */howto. But when i run the the "make world" I have an error with the studbom compilation : /Dans le fichier

Is there any support for x86_64 pthreads for mini-OS ? Does the current newlib contains a functional implementation of pthreads ? -- Karim Allah Ahmed. LinkedIn <http://eg.linkedin.com/pub/karim-allah-ahmed/13/829/550/> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

stubdom: prevent newlib from emiting cli/sti in longjmp Also fix build dependencies and cleanup. Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com> diff -r b320cfe1f10f stubdom/Makefile --- a/stubdom/Makefile Thu Jun 05 13:04:07 2008 +0100 +++ b/stubdom/Makefile Fri Jun 06 16:00:35 2008 +0100 @@ -23,9 +23,11 @@ ifeq ($(GNU_TARGET_ARCH), i686) TARGET_CFLAGS=

minios: support COW for a zero page Permits to support sparse data. Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com> diff -r 27ad7ed41be2 extras/mini-os/arch/x86/mm.c --- a/extras/mini-os/arch/x86/mm.c Fri Jan 18 15:55:13 2008 +0000 +++ b/extras/mini-os/arch/x86/mm.c Fri Jan 18 16:02:32 2008 +0000 @@ -50,6 +50,7 @@ #endif unsigned long *phys_to_machine_mapping; +unsigned

I am trying to build xen-3.3.0 and I keep running into this error. I have checked and everything is there and installed and the PATH is correct. I found someone on the 15th who also had the same problem but never got a reply back so I am asking again. Here is the error: make[2]: Entering directory `/usr/src/xen-3.3.0/extras/mini-os'' [ -e include/xen ] || ln -sf

Add a thread watching the xenbus shutdown control path and notifies a wait queue. Add HYPERVISOR_shutdown convenient inline for minios shutdown. Add proper shutdown to the minios test application. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> diff -r fdf241ea6ff4 extras/mini-os/include/kernel.h --- a/extras/mini-os/include/kernel.h Wed Nov 28 21:29:18 2012 +0100 +++

[PATCH] minios: end watch of FS backend state value Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com> diff -r 48925b5a5d53 extras/mini-os/fs-front.c --- a/extras/mini-os/fs-front.c Fri May 02 12:21:27 2008 +0100 +++ b/extras/mini-os/fs-front.c Fri May 02 14:11:45 2008 +0100 @@ -1028,6 +1028,7 @@ done: /* The token will not be unique if multiple imports are inited */

minios: fix p2m on x86 15675:bf85b467ee89 Fixed p2m on x86_64, but instead broke it on x86. Signed-off-by: Samuel Thibault <samuel.thibaut@ens-lyon.org> diff -r 8df3c145923f extras/mini-os/arch/x86/mm.c --- a/extras/mini-os/arch/x86/mm.c Mon Jan 19 17:40:28 2009 +0000 +++ b/extras/mini-os/arch/x86/mm.c Sat Feb 07 03:44:41 2009 +0100 @@ -550,9 +550,15 @@ void arch_init_p2m(unsigned long

minios: fix and enforce block_domain atomicity To ensure that the timer event is not lost, block_domain requires that event delivery is disabled. SCHEDOP_block re-enables them, so for coherency (and fixing a bug actually), we should re-disable them after. Also, make sure that the caller disabled them. Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com> diff -r 4965e711fee8

Hello, as some might have read in my previous postings, I have a Mini-OS dom0 that constructs a Mini-OS domU on x86 xen-3.0.4-testing. As the memory layout my Dom0 builds does not guarantee, that pages the DomU Mini-OS tries to use as page tables are mapped to existing memory, I changed new_pt_frame in arch/x86/mm.c in the following way: The pt_pfn is mapped R/W, then it is zeroed by a

Hello, sorry to bother you with this: while trying to compile mini-os from xen-unstable.hg, I noticed that compilation failed like this: gcc -fno-builtin -Wall -Werror -Wredundant-decls -Wno-format -Wstrict-prototypes -Wnested-externs -Wpointer-arith -Winline -m32 -march=i686 -g -Iinclude -Iinclude/x86 -Iinclude/x86/x86_32 -c gnttab.c -o gnttab.o gnttab.c: In Funktion »init_gnttab«:

stubdom: fix build dependency newlib now depends on mini-os header links diff -r 4c2d9a4d11f2 stubdom/Makefile --- a/stubdom/Makefile Fri Jul 18 13:58:29 2008 +0100 +++ b/stubdom/Makefile Fri Jul 18 14:19:52 2008 +0100 @@ -86,7 +86,7 @@ NEWLIB_STAMPFILE=$(CROSS_ROOT)/$(GNU_TARGET_ARCH)-xen-elf/lib/libc.a .PHONY: cross-newlib cross-newlib: $(NEWLIB_STAMPFILE) -$(NEWLIB_STAMPFILE):

Does this install -d -m0755 -p "/mnt/gen2/TmpDir/portage/app-emulation/xen-pvgrub-4.3.0/image//usr/lib/xen/boot" install -m0644 -p mini-os-x86_32-grub/mini-os.gz "/mnt/gen2/TmpDir/portage/app-emulation/xen-pvgrub-4.3.0/image//usr/lib/xen/boot/pv-grub-x86_32.gz" make: Leaving directory `/mnt/gen2/TmpDir/portage/app-emulation/xen-pvgrub-4.3.0/work/xen-4.3.0/stubdom'

Hi all, All of a sudden my xend is crashing, when i do "xm create domu" due to which the domains are created in paused state. Iam using minios as domU kernel, but the problem occurs even for linux-2.6.18.1 pv kernel as domu kernel. xend.log shows [2008-07-31 03:00:54 14821] CRITICAL (SrvDaemon:231) Xend died due to signal 11! Restarting it.... after doing some preliminary

Does anyone on this list have experience with newlib? I'm thinking of porting newlib to the COM32 environment, rather than trying to hack my own mini-libc. I just wondered if anyone had any idea of how well that would be likely to work, and/or how well newlib works from a code size standpoint... -hpa