Mini-os buglet (integer in xenbus/xenbus_xs.c should be unsigned)

Mini-os buglet (integer in xenbus/xenbus_xs.c should be unsigned)

[John D. Ramsdell]

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]#

Re: Mini-os buglet (integer in xenbus/xenbus_xs.c should be unsigned)

[Ewan Mellor]

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.

Re: Mini-os buglet (integer in xenbus/xenbus_xs.c should be unsigned)

[Ewan Mellor]

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.

Mini-os with Lua

[John D. Ramsdell]

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

Re: Mini-os with Lua

[John D. Ramsdell]

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

Re: Mini-os with Lua

[Grzegorz Milos]

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

Re: Mini-os with Lua

[John D. Ramsdell]

> From: Grzegorz Milos <gm281@cam.ac.uk>

> 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).

Thank you for the information.  I finished the patch required to make
Lua use no floating point operations, and am looking at how to expose
inter-VM communication to applications written in Lua embedded in the
Mini-OS kernel. 

http://www.ccs.neu.edu/home/ramsdell/tools/lua-5.1-no-fp.patch

John