From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id B7D09BC37 for ; Thu, 28 Jan 2010 14:27:32 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,359,1262559600"; d="scan'208";a="54851843" Received: from unknown (HELO const.ipv6) ([193.50.110.76]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 28 Jan 2010 14:27:32 +0100 Received: from samy by const.ipv6 with local (Exim 4.71) (envelope-from ) id 1NaUPD-0002OL-AC for caml-list@yquem.inria.fr; Thu, 28 Jan 2010 14:27:31 +0100 Resent-From: Samuel Thibault Resent-Date: Thu, 28 Jan 2010 14:27:31 +0100 Resent-Message-ID: <20100128132731.GA9188@const.bordeaux.inria.fr> Resent-To: caml-list@yquem.inria.fr Date: Thu, 28 Jan 2010 14:18:32 +0100 From: Samuel Thibault To: Konstantin Tcholokachvili Subject: Re: [Caml-list] Ocaml implementation and low level details Message-ID: <20100128131832.GX4873@const.bordeaux.inria.fr> References: <20100128125530.GS4873@const.bordeaux.inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.12-2006-07-14 X-Spam: no; 0.00; thibault:01 thibault:01 ocaml:01 0100,:01 browsed:01 ocaml:01 caml-managed:01 iirc:01 -unsafe:01 threads:01 garbage:01 rewrite:01 heap:01 caml-list:01 caml:02 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