John D. Ramsdell
2006-Apr-05 15:34 UTC
[Xen-devel] Mini-os buglet (integer in xenbus/xenbus_xs.c should be unsigned)
I''m running on a 32-bit x86 machine with Fedora Core 5. There is a
problem that causes a compilation failure when building mini-os from
its sources. An integer in xenbus/xenbus_xs.c should be unsigned.
Furthermore, a use of "xm top" asks me to report a bug to this list.
John
$ diff -ur oxen-3.0.1 xen-3.0.1
Only in xen-3.0.1/extras/mini-os: events.o
Only in xen-3.0.1/extras/mini-os: hypervisor.o
Only in xen-3.0.1/extras/mini-os/include: xen
Only in xen-3.0.1/extras/mini-os: kernel.o
Only in xen-3.0.1/extras/mini-os/lib: math.o
Only in xen-3.0.1/extras/mini-os/lib: printf.o
Only in xen-3.0.1/extras/mini-os/lib: string.o
Only in xen-3.0.1/extras/mini-os/lib: xmalloc.o
Only in xen-3.0.1/extras/mini-os: mini-os.elf
Only in xen-3.0.1/extras/mini-os: mini-os.gz
Only in xen-3.0.1/extras/mini-os: mm.o
Only in xen-3.0.1/extras/mini-os: sched.o
Only in xen-3.0.1/extras/mini-os: time.o
Only in xen-3.0.1/extras/mini-os: traps.o
Only in xen-3.0.1/extras/mini-os: x86_32.o
Only in xen-3.0.1/extras/mini-os/xenbus: xenbus_comms.o
diff -ur oxen-3.0.1/extras/mini-os/xenbus/xenbus_xs.c
xen-3.0.1/extras/mini-os/xenbus/xenbus_xs.c
--- oxen-3.0.1/extras/mini-os/xenbus/xenbus_xs.c 2006-03-01 17:38:57.000000000
-0500
+++ xen-3.0.1/extras/mini-os/xenbus/xenbus_xs.c 2006-04-05 10:56:21.000000000
-0400
@@ -335,7 +335,7 @@
const char *dir, const char *node)
{
char **d;
- int dir_n;
+ unsigned int dir_n;
d = xenbus_directory(t, dir, node, &dir_n);
if (IS_ERR(d))
Only in xen-3.0.1/extras/mini-os/xenbus: xenbus_xs.c~
Only in xen-3.0.1/extras/mini-os/xenbus: xenbus_xs.o
Only in xen-3.0.1/extras/mini-os/xenbus: xenstored.h
[ramsdell@goo mini-os]$ su
Password:
[root@goo mini-os]# pwd
/home/ramsdell/src/xen-3.0.1/extras/mini-os
[root@goo mini-os]# /usr/sbin/xm create domain_config
Using config file "domain_config".
Started domain Mini-OS
[root@goo mini-os]# /usr/sbin/xm top
Unexpected error: exceptions.OSError
Please report to xen-devel@lists.xensource.com
Traceback (most recent call last):
File "/usr/sbin/xm", line 10, in ?
main.main(sys.argv)
File "/usr/lib/python2.4/site-packages/xen/xm/main.py", line 1021,
in main
rc = cmd(args)
File "/usr/lib/python2.4/site-packages/xen/xm/main.py", line 654, in
xm_top
os.execvp(''xentop'', [''xentop''])
File "/usr/lib/python2.4/os.py", line 341, in execvp
_execvpe(file, args)
File "/usr/lib/python2.4/os.py", line 379, in _execvpe
func(fullname, *argrest)
OSError: [Errno 2] No such file or directory
[root@goo mini-os]# /usr/sbin/xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 1416 1 r----- 41.9
Mini-OS 1 32 1 ------ 8.6
[root@goo mini-os]# /usr/sbin/xm destroy Mini-OS
[root@goo mini-os]# /usr/sbin/xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 1416 1 r----- 46.2
[root@goo mini-os]#
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ewan Mellor
2006-Apr-05 15:47 UTC
Re: [Xen-devel] Mini-os buglet (integer in xenbus/xenbus_xs.c should be unsigned)
On Wed, Apr 05, 2006 at 11:34:47AM -0400, John D. Ramsdell wrote:> Furthermore, a use of "xm top" asks me to report a bug to this list.Could you open a bug in Bugzilla, please, and run xen-bugtool to attach your logs to it? Thanks, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ewan Mellor
2006-Apr-06 14:12 UTC
Re: [Xen-devel] Mini-os buglet (integer in xenbus/xenbus_xs.c should be unsigned)
On Wed, Apr 05, 2006 at 11:34:47AM -0400, John D. Ramsdell wrote:> I''m running on a 32-bit x86 machine with Fedora Core 5. There is a > problem that causes a compilation failure when building mini-os from > its sources.Thanks for that patch to mini-os. The file in question was actually removed from xen-unstable a couple of weeks ago, so there''s no problem any longer! Thanks anyway, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ewan Mellor <ewan@xensource.com> writes:> Thanks for that patch to mini-os. The file in question was actually > removed from xen-unstable a couple of weeks ago, so there''s no > problem any longer!The reason I was running the mini-os, is that I was thinking about using it to implement programs that run in lightweight virtual machines. It appears from your note that mini-os is changing, and I hope it is not changing in a way that is incompatible with the way I in which I had hoped to use it. Let me describe my plan. I would like to run reactive programs in the style used by old distributed memory parallel processors. In this style, a program registers handlers for events, and then exits. Actual computation occurs in a thread created by the operating system to handle an event. Each thread is required to be short lived, so the cooperative scheduler that is in the mini-os is appropriate for this programming model. To ease the programming task, I would like to implement the handlers in Lua <http://www.lua.org>, a scripting language popular with the small device community. Lua is appropriate because it can be built so that it performs no floating point operations, and its garbage collector is incremental, so that pause times are small. This allows it to be used with a reactive programming model inside the kernel. The C library that is part of mini-os in inadequate for use with Lua, however, one can build a cross-compiler that can do the job. To do so, one downloads the sources for binutils, gcc, and newlib <http://sources.redhat.com/newlib/>, and builds a cross-compiler for the target i386-elf. In addition to linking ones program with libc, and libm, one also uses libnosys, which stubs all system calls. I built mini-os with the cross-compiler, and verified it runs in Xen. I have also built Lua with it so as to ensure that all of its globals are resolved by newlib. Lua can be useful with stub routines for system calls, however, there is one more support item it requires. It needs an allocator that functions like realloc, or a good implementation of the sbrk system call. Since mini-os contains an implementation of malloc and free, hacking in support for realloc seems to be the best option to me. The remaining step is to write C functions that expose hypercall functionality inside of Lua. Since Lua is designed to be embedded into C programs, this task should be easy. I was just about to start writing these functions when you raised my concerns about mini-os''s direction. Where is it headed, and will it continue to provide the kind of platform that supports reactive programming? John _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
ramsdell@mitre.org (John D. Ramsdell) writes:> The C library that is part of mini-os in inadequate for use with > Lua, however, one can build a cross-compiler that can do the job. > ... > I have also built Lua with it so as to ensure that all of its > globals are resolved by newlib.Actual, not all the globals were resolved by newlib. Lua uses the time system call, but it can easily be implemented in terms of gettimeofday. John _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi John, We are currently working on getting Mini-os to work on 64 bit architecture and doing some debugging work. You therefore don''t have to worry about semantic changes (for example changing the scheduler). Small code base and simplicity of Mini-os makes it suitable for projects like yours (we have a few of them here as well). From the Mini-os development point of view the more stress tests should expose more bugs. So please keep in touch (write to me directly), especially if you experience any Mini-os misbehaviors. Cheers Gregor John D. Ramsdell wrote:> Ewan Mellor <ewan@xensource.com> writes: > >> Thanks for that patch to mini-os. The file in question was actually >> removed from xen-unstable a couple of weeks ago, so there''s no >> problem any longer! > > The reason I was running the mini-os, is that I was thinking about > using it to implement programs that run in lightweight virtual > machines. It appears from your note that mini-os is changing, and I > hope it is not changing in a way that is incompatible with the way I > in which I had hoped to use it. Let me describe my plan. > > I would like to run reactive programs in the style used by old > distributed memory parallel processors. In this style, a program > registers handlers for events, and then exits. Actual computation > occurs in a thread created by the operating system to handle an event. > Each thread is required to be short lived, so the cooperative > scheduler that is in the mini-os is appropriate for this programming > model. > > To ease the programming task, I would like to implement the handlers > in Lua <http://www.lua.org>, a scripting language popular with the > small device community. Lua is appropriate because it can be built so > that it performs no floating point operations, and its garbage > collector is incremental, so that pause times are small. This allows > it to be used with a reactive programming model inside the kernel. > > The C library that is part of mini-os in inadequate for use with Lua, > however, one can build a cross-compiler that can do the job. To do > so, one downloads the sources for binutils, gcc, and newlib > <http://sources.redhat.com/newlib/>, and builds a cross-compiler for > the target i386-elf. In addition to linking ones program with libc, > and libm, one also uses libnosys, which stubs all system calls. I > built mini-os with the cross-compiler, and verified it runs in Xen. I > have also built Lua with it so as to ensure that all of its globals > are resolved by newlib. > > Lua can be useful with stub routines for system calls, however, there > is one more support item it requires. It needs an allocator that > functions like realloc, or a good implementation of the sbrk system > call. Since mini-os contains an implementation of malloc and free, > hacking in support for realloc seems to be the best option to me. > > The remaining step is to write C functions that expose hypercall > functionality inside of Lua. Since Lua is designed to be embedded > into C programs, this task should be easy. I was just about to start > writing these functions when you raised my concerns about mini-os''s > direction. Where is it headed, and will it continue to provide the > kind of platform that supports reactive programming? > > John > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel