Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Ocaml implementation and low level details
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Konstantin Tcholokachvili <tcholoka@g...>
Subject: Re: [Caml-list] Ocaml implementation and low level details
2010/1/28 Samuel Thibault <>

> Konstantin Tcholokachvili, le Thu 28 Jan 2010 14:10:27 +0100, a écrit :
> > I browsed the sources of funk OS one year ago, if I remember corectly you
> are
> > one og its author.
> Yep :)
> > I assume that if funk manages memory and run threads it's possible to
> code an
> > OS from ground up using Ocaml but want to be sure:
> >
> > - Does I need to disable an option to avoid the garbage collector's use?
> (I
> > gues that yes)
> We didn't need to. All caml-managed memory is in the heap. Of course for
> page tables you can not allocate them in the garbage-collected area.
> > - Also need I disable Ocaml theading subsystem? (Obviously yes, but are
> there
> > some limitations?)
> IIRC we just needed to port it.

OK but as there is a giant lock (as I heard), I'm afraid that the
multithreading subsystem of my kernel will suffer from that.
Am I correct?

> > Are there other important considerations to take?
> In my memory, mostly the direct access to some kinds of memory, like the
> video memory: we faked a string with the -unsafe option to get efficient
> direct access.

So must I also make tricks to have DMA acess?

> > Do you think that Ocaml is suitable for OS coding (I''m using C now).
> It's much better for all the programmability & safety reasons. Funk
> showed that it is possible. Performance should be quite good.  Now the
> pragmatic answer would be that Linux already works quite well and has
> all the drivers we need, while yet another new kernel would have to
> rewrite them all. And about performance, when you see how much Linux
> people care about tiny details in their lock implementation etc., a caml
> implementation wouldn't suit that.

My goal isn't to have a kenel portable across many platforms but only to
some kind of hardware.
It's a hobby project.
Why caml's implementation wouldn't be suitable? Because of the giant lock as
I mentioned before?

> To sum it up: to get a safe working kernel, caml should be fine. To get
> a kernel that works on most hardware and is as efficient as possible,
> just take Linux :/

> Samuel

Konstantin Tcholokachvili