[Haskell] A road for Haskell into the kernel of a full-fledged OS

[ol...@pobox.com]

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...

_______________________________________________
Haskell mailing list
Has...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Joel Reymont]

On Jun 2, 2006, at 5:41 PM, ol...@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/

[Greg Buchholz]

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

[Isaac Jones]

Joel Reymont <joe...@gmail.com> writes:

> On Jun 2, 2006, at 5:41 PM, ol...@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

[Jaap Weel]

> 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

[Bulat Ziganshin]

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.Z...@gmail.com