[Nestedvm] Ponderings...

[Thorbjørn Ravn Andersen]

I've been interested in the NestedVM project for quite a while, as I 
really would like a Java-only rsync for various reasons.

Additionally I bought a WD TV LIve thing for watching movies.  It 
quickly turned out it is MIPS-based and that a chrooted Debian mipsel 
Lenny is available which with very little effort can have gcc installed 
and produce MIPS-binaries.  This is interesting for NestedVM for several 
reasons:

* NestedVM is based on a cross-compiling gcc-3.3 which does not easily 
build on recent Linux distributions.

* The NestedVM MIPS "cpu" is hacked from the original MIPS-hardware to 
make it run.  This means that this is for all practically purposes a new 
hardware platform which is unsupported by everything else.  That was 
fine for the original usage, but for long term maintainance that is not 
such a good idea.  This is apparently both for the CPU emulation and the 
standard runtime library.

* NestedVM is based on big-endian MIPS, and most moderne hardware runs 
as little-endian MIPS.  From what I understand from the current sources, 
in order to have NestedVM support both this is primarily an issue of 
making the DataInputStream wrapped around SHeader.getInputStream() be 
aware of the endianess when calling readInt() (which is a bit tricky as 
it is final).

 From a pure maintainance point of view I would suggest that it would be 
very beneficial to adapt the NestedVM "platform" from the current 
cross-compiler to a standard Debian MIPS distribution using as many 
standard packages as possible allowing for almost any modern router to 
function as a NestedVM buildbox, as well as Debian Linux running on QEMU.

I've found that this guy maintains QEMU images  for several platforms 
http://www.aurel32.net/info/debian_mips_qemu.php including both mips and 
mipsel and I've succesfully but slowly run the mipsel image on qemu 0.10 
under Ubuntu.   Hence, here is a real, maintained platform that could be 
used!


If that can be done, then I would suggest that the next step would be 
looking into the following:

* Port the current heap access to use NIO instead of a double indexed 
array.  NIO apparently has a 2 Gb address space instead of the 64 kb 
page size when using arrays.

* Look into what it takes to have dynamic linkage in Java instead of gcc 
producing static binaries.

* Improve Unix runtime support (so rsync will run :) )


Any comments?

-- 

  Thorbjørn Ravn Andersen  "...plus... Tubular Bells!"