New challenges ahead
norman.feske at ...1...
Sat Mar 26 19:21:57 CET 2011
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
> * 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  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.
Dr.-Ing. Norman Feske
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
More information about the users