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 2D9C5BC37 for ; Thu, 28 Jan 2010 14:45:31 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,359,1262559600"; d="scan'208";a="54852982" 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:45:30 +0100 Received: from samy by const.ipv6 with local (Exim 4.71) (envelope-from ) id 1NaUgc-0002i6-Hp; Thu, 28 Jan 2010 14:45:30 +0100 Date: Thu, 28 Jan 2010 14:45:30 +0100 From: Samuel Thibault To: Konstantin Tcholokachvili Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Ocaml implementation and low level details Message-ID: <20100128134530.GD4873@const.bordeaux.inria.fr> References: <20100128125530.GS4873@const.bordeaux.inria.fr> <20100128131832.GX4873@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 ocaml:01 iirc:01 -unsafe:01 runtime:01 pointers:01 caml's:01 alignment:01 2.0:98 hobby:98 garbage:01 rewrite:01 Konstantin Tcholokachvili, le Thu 28 Jan 2010 14:35:50 +0100, a écrit : > > - 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? Ah, the kernel can't be running concurrently, yes. Just like Linux 2.0 was working, actually. > > 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? Yes, unless you get hooks into the caml runtime to be notified of garbage collection, to update pointers & such. > > 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. Ok, then you can probably start with the current funk testbed :) > Why caml's implementation wouldn't be suitable? Because of the giant lock as I > mentioned before? Because you do not have as much control over e.g. data alignment & such as in C. Linux people spend quite some time fine-tuning such small details and get performance benefits. Samuel