Hello Thomas,
thank you very much for this background information. I suppose, we should rephrase the HalVM topic, putting the focus on the actual Haskell runtime but leaving the actual approach more open. I'd reference HalVM and House as the projects that lead the way towards using Haskell as systems language.
- About Me and HaLVM
I'm a PhD student under Andrew Tolmach (original developer of the HaLVM) and have used HaLVM in the past (but not been involved with its development). Our group [1] is working on defining and building a compiler for the Habit programming language (once called "Systems Haskell"). Part of that work involves building demo projects, which will likely be a Habit-HaLVM and part of an L4 kernel.
Very interesting. Thanks for the pointers!
- About HaLVM and House (and "Linux Kernel Modules in Haskell")
The GHC patches developed for HaLVM remove all dynamic allocation, assumptions about the existence of a file system, etc. For this reason, the same patches were used in the House and Linux module work. Not sure how much this matches with the Genode framework (as much as I've played with installing Genode and associated kernel I never really looked at the API).
The information about the removal of dynamic memory allocation is new to me. This is actually a critical point in the context of Genode because on Genode, multi-level servers (services that are used by multiple clients, which mistrust each other) are designed such that server-side allocations are accounted per client rather then obtained from an anonymous heap. This way, these critical servers become robust against resource-exhaustion-based denial-of-service problems. However, the per-client accounting of server-side allocations (which we call heap partitioning) seems to inherently contradict with the idea of transparent memory management as found in most high-level language runtimes. It is good to know that this problem is recognized.
From the information I gathered from browsing the HalVM source code, it
looks like HalVM pretty much abstracts-away the underlying Xen API (e.g., via libIVC) such that the code written ontop of these libraries could be reused in a non-Xen environment such as Genode.
Best regards Norman