The unique anykernel capability of NetBSD allows the creation of rump kernels, which are partially paravirtualized kernels running on top of a high-level hypervisor. This technology e.g. enables running the same file system driver in the monolithic kernel or as a microkernel style server in userspace. POSIX-compatible systems have been more or less supported as rump kernel hypervisors for the past 5 years. A long-time goal has been to extend hypervisor support further, for example to embedded systems. This would bring the solid driverbase of NetBSD available to such systems with only the cost of implementing the hypervisor.

To see how far things can go, last week I started toying with the idea of using a javascript engine as a rump kernel hypervisor. I was planning to compile the NetBSD kernel sources into javascript and manually implement the hypervisor. After some searching for a C->javascript compiler, I found emscripten, which translates C into javascript via LLVM bitcode. Not only is the compiler itself extremely mature, but there is also extensive support for the POSIX API. This meant that I could not only compile the kernel drivers to javascript with emscripten, I could also compile the existing POSIX hypervisor and have it work.

The approach of compiling kernel drivers into javascript allows them to be directly accessed from existing javascript code. Yes, I did add a sys/arch/javascript into the kernel source tree. This contrasts the approach taken by another similar experiment, where an x86 Linux is run inside a x86 machine emulator running in a javascript engine.

I have thrown together a small proof-of-concept demo of how to build a web service with the capability to access file system images using kernel file system drivers compiled to javascript. I compiled a rump kernel with support for the FFS, tmpfs and kernfs file systems. This rump kernel backend is tied to a lightweight web page which passes requests from forms to the rump kernel and displays results. When the javascript is run, it downloads an FFS image (rump.data), bootstraps a rump kernel, and mounts the FFS image r/o at /ffs. The status can be further manipulated with interactive commands.

The demo is available here. I've tested it to work with Firefox and tested it to not work with Internet Explorer. YMMV with other browsers. Note, the javascript and the FFS image together are close to 5.5MB in size, so the page may load for a few moments over a slow link -- javascript is not exactly compact and whitespace removal was the only size reduction technique I used. If you're interested in comparing the generated javascript with the C sources, you can also look at the unoptimized version (14MB).

Posted Wednesday night, November 7th, 2012 Tags:
The driver for A2000-style Real Time Clock modules (popular also on A1200 CPU cards) had bit-rotted so far as to be useless. It was rewritten as machine-independent msm6242b(4) driver, with amiga-specific frontend under old a2kbbc(4) name.
Posted at midnight, November 14th, 2012 Tags:

The first release candidate of NetBSD 5.2 is now available for download at: http://ftp.NetBSD.org/pub/NetBSD/NetBSD-5.2_RC1/

NetBSD 5.2 is intended for those who have an application using NetBSD 5.0.x or 5.1.x who don't want the churn of upgrading to NetBSD 6.0, but would like bug fixes and some stable new features. There have been a number of changes since 5.1. See src/doc/CHANGES-5.2 for the full list.

Those of you who prefer to build from source can continue to follow the netbsd-5 branch, but the netbsd-5-2-RC1 tag is available as well.

Please help us test this and any upcoming release candidates as much as possible. Remember, any feedback is good feedback. We'd love to hear from you, whether you've got a complaint or a compliment.

Posted Wednesday evening, November 14th, 2012 Tags:
The xsurf(4) driver was extended to support IDE controller present on Individual Computers X-Surf cards.
Posted at midnight, November 19th, 2012 Tags:
The new z3rambd(4) driver allows using Zorro III RAM boards (like ZorRAM and BigRamPlus) as swap space. If the kernel is built without this driver, it is also possible to use these boards as normal RAM memory in some configurations (which was the usual behaviour). However, it might have performance consequences, it is advised to use Zorro III RAM as swap space where possible.
Posted at midnight, November 26th, 2012 Tags:
Add a comment