A road for Haskell into the kernel of a full-fledged OS
I'm attending a USENIX conference and just had a nice talk with Andrew Tanenbaum. As some may know, he's working on the new version of Minix, Minix3. It is actually working, now with the X windows interface: http://www.minix3.org Andrew Tanenbaum said that it is important for a language like OCaml or Haskell to get more visibility among the OS developers; and Minix offers a very good way to do that. Minix3 is based on micro-kernel; all of the OS services (memory manager, file system, all the drivers, etc.) run as regular processes communicating through a well-defined protocol. It is irreleveant what language these services are written in, so long as they obey the protocol. Some of Andrew Tanenbaum's students are interested in re-writing some of Minix3 OS services (like device drivers or file systems, currently written in C) in Ocaml and Cyclone. He is interested in the outcome. Haskell is a good candidate too. It is quite instructive to compare a device driver in Haskell with the original C driver -- it terms of length, speed, time to write, number of bugs, etc. Andrew Tananbaum suggested that the terminal driver may be the best start, because it is quite stand-alone, small and its protocol is simple. With Minix, we can replace one kernel service of the full-fledged, working OS with the one written in Haskell -- and immediately see how it all works. If it doesn't, the rest of OS still works and so we can unload the faulty service and load another implementation. Minix3 does indeed offer an easy road to the OS kernel for a language other than C. I said that there may be quite a bit of interest in Haskell community in such a project. I wonder if I'm right...
On Jun 2, 2006, at 5:41 PM, oleg@pobox.com wrote:
It is quite instructive to compare a device driver in Haskell with the original C driver -- it terms of length, speed, time to write, number of bugs, etc.
I think this is an awesome idea. I believe the folks at Galois have customized the Haskell runtime for embedded devices but... I wonder if us mere mortals will spend more time fighting laziness (and thus high memory usage) than focusing on driver functionality. Thanks, Joel -- http://wagerlabs.com/
Joel Reymont wrote:
I think this is an awesome idea. I believe the folks at Galois have customized the Haskell runtime for embedded devices but... I wonder if us mere mortals will spend more time fighting laziness (and thus high memory usage) than focusing on driver functionality.
In a similar vein, the Coyotos Project ( http://coyotos.org/ ) is writing their own language, BitC, to support their microkernel... http://www.coyotos.org/docs/bitc/spec.html "BitC is conceptually derived in various measure from Standard ML, Scheme, and C. Like Standard ML [10], BitC has a formal semantics, static typing, a type inference mechanism, and type variables. Like Scheme [8], BitC uses a surface syntax that is readily represented as BitC data. Like C [1], BitC provides full control over data structure representation, which is necessary for high-performance systems programming. The BitC language is a direct expression of the typed lambda calculus with side effects, extended to be able to reflect the semantics of explicit representation." Greg Buchholz
Joel Reymont <joelr1@gmail.com> writes:
On Jun 2, 2006, at 5:41 PM, oleg@pobox.com wrote:
It is quite instructive to compare a device driver in Haskell with the original C driver -- it terms of length, speed, time to write, number of bugs, etc.
I think this is an awesome idea. I believe the folks at Galois have customized the Haskell runtime for embedded devices but... I wonder if us mere mortals will spend more time fighting laziness (and thus high memory usage) than focusing on driver functionality.
Another interesting Galois-related low-level project is the Halfs filesystem: http://www.haskell.org/halfs/ Oleg, did you happen to mention this to Andrew Tanenbaum? Do you think he'd be interested in looking at it? Should I drop him a line? peace, isaac
It is irreleveant what language these services are written in, so long as they obey the protocol.
This is most likely true. I have written an interface using the OCaml FFI to be able to call the MINIX message passing functions from within an OCaml program. It's doesn't work completely just yet, but most of it's there. One practical problem is that the "protocol" is not specificied clearly or in a single place. Currently, I can use the message passing interface from OCaml to perform system calls from user processes. In particular, I have implemented a rudimentary kill(1) utility that uses the message passing interface directly, without going through the C library kill() function. I have not yet written a working device driver using my interface, but last night I got a lot closer to catching the last bug...
Some of Andrew Tanenbaum's students are interested in re-writing some of Minix3 OS services (like device drivers or file systems, currently written in C) in Ocaml and Cyclone.
That would be me. The project page is at https://gforge.cs.vu.nl/projects/ominix/ I would also be interested in using Haskell. I wrote a little compiler (for the BlooP/FlooP language from Hofstadter's "Goedel, Escher, Bach") in Haskell last year for a project supervised by Mike Vanier when I was an undergrad at Caltech. You can find it somewhere on my web site http://www.ugcs.caltech.edu/~weel I like Haskell a lot, but I chose to use OCaml for this work because the practicalities of porting the compiler were a little easier to manage. GHC would be rather harsh on the fairly primitive MINIX memory management system, although I must admit I have not yet tried to port Haskell to MINIX, so this is purely a conjecture. The current version on the project page only works with MINIX from CVS. I could make it work with 3.1.2, but then it would stop working with the CVS version. This is because the interface files have to duplicate some information about the kinds of messages that exist and what their tags are, which must be synchronized with the OS's idea of what the tags mean. -- /jaap
Hello Jaap, Friday, June 16, 2006, 7:27:32 PM, you wrote:
I like Haskell a lot, but I chose to use OCaml for this work because the practicalities of porting the compiler were a little easier to manage. GHC would be rather harsh on the fairly primitive MINIX memory management system, although I must admit I have not yet tried to port Haskell to MINIX, so this is purely a conjecture.
afaik, GHC is very primitive in this area - it just eats OS memory in megabyte chunks and never returns it back. also, if you don't search for speed (and in terms of low-level speed even GHC is far away from OCaml), you can try YHC compiler - it requires less memory and time for compilation and in overall designed as highly portable Haskell compiler with best debugging facilities -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
participants (6)
-
Bulat Ziganshin -
Greg Buchholz -
Isaac Jones -
Jaap Weel -
Joel Reymont -
oleg＠pobox.com