[Nestedvm] Ponderings...

[Charles Oliver Nutter]

This sounds like some spectacular research you have done!

On a separate email, I have been discussing ways to make NestedVM more
usable. So far we have considered the following possibilities:

* adding a function-calling API based on Wayne Meissner's jaffl
library. He already has a start on this at his github project under
github.com/wmeissner
* providing a prepared VitrualBox VM with the toolchain preinstalled.
This may be available very soon.
* building the toolchain for MIPS directly, so it can be run on
NestedVM directly. This will take some time and hackery for sure.

The improvements you suggest all sound very logical. Perhaps we need
to find someone acting as "lead" of NestedVM to spin up a real bug
tracker and project site so we can start making a real go at this? The
success of libraries like sqlite-jdbc show me that this thing has
legs.

On Sunday, February 21, 2010, Thorbjørn Ravn Andersen
<nospam0002 at gmail.com> wrote:
> 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!"
>
>
> _______________________________________________
> Nestedvm mailing list
> Nestedvm at lists.hcoop.net
> https://lists.hcoop.net/listinfo/nestedvm
>