2010/1/28 Samuel Thibault
<samuel.thibault@inria.fr>
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