From: Samuel Thibault <samuel.thibault@inria.fr>
To: Konstantin Tcholokachvili <tcholoka@gmail.com>
Subject: Re: [Caml-list] Ocaml implementation and low level details
Date: Thu, 28 Jan 2010 14:18:32 +0100 [thread overview]
Message-ID: <20100128131832.GX4873@const.bordeaux.inria.fr> (raw)
In-Reply-To: <ecafee001001280510t10cde708h7e2d258629cb0f9c@mail.gmail.com>
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.
> 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.
> 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.
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
next prev parent reply other threads:[~2010-01-28 13:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-28 12:42 Konstantin Tcholokachvili
2010-01-28 12:55 ` [Caml-list] " Samuel Thibault
[not found] ` <ecafee001001280510t10cde708h7e2d258629cb0f9c@mail.gmail.com>
2010-01-28 13:12 ` Konstantin Tcholokachvili
2010-01-28 13:18 ` Samuel Thibault [this message]
2010-01-28 13:35 ` Konstantin Tcholokachvili
2010-01-28 13:45 ` Samuel Thibault
2010-01-28 17:28 ` Konstantin Tcholokachvili
2010-01-28 17:47 ` Basile STARYNKEVITCH
2010-01-28 18:39 ` Richard Jones
2010-01-28 20:22 ` Goswin von Brederlow
2010-01-28 21:16 ` Konstantin Tcholokachvili
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100128131832.GX4873@const.bordeaux.inria.fr \
--to=samuel.thibault@inria.fr \
--cc=tcholoka@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox