Re: [Caml-list] Ocaml implementation and low level details

[Konstantin Tcholokachvili <tcholoka@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]

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
>


Konstantin Tcholokachvili

[-- Attachment #2: Type: text/html, Size: 3455 bytes --]