From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 6473BBC37 for ; Thu, 28 Jan 2010 14:35:52 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowBABYhYUvRVdvakGdsb2JhbACRQIlPPQEBAQEJCQwHEwOvCYFFhTCINwEBAwWENwQ X-IronPort-AV: E=Sophos;i="4.49,359,1262559600"; d="scan'208";a="42366918" Received: from mail-ew0-f218.google.com ([209.85.219.218]) by mail2-smtp-roc.national.inria.fr with ESMTP; 28 Jan 2010 14:35:52 +0100 Received: by ewy10 with SMTP id 10so774028ewy.3 for ; Thu, 28 Jan 2010 05:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=JJ5xMeNe3MzwKjWKLpR776T4UBXGCKNggtmzhDau+68=; b=ovzWfZHvrmPuUNGJ4e2BEoWOScr9hF52XOZZDsGh/GCFJ6EpcNLoEvZK/eQDf8+Dcu Hl/S0mvEXT/eAz0e4KQFJoBm5SjCfxGCbfyfKze0enRyg68OutLL77fzw2ihoa1Bn4ii IAgpyvL9bkRZ2xPuU0/MJ4iz93AwvuCpbA6qE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vkepJyIfRBJ7Kzb/4MIN9kO3iioFjSnUghDP4ReJJXBFsyizNdGkRYE0y+atjrsgCP WAVzaCV2df6QEZGNmYtzTEyBY6EwoSmf327r9pLuMatUtH54snQoizNLPm0K2YQwXVb1 BtPlx7QVUs2sQSMH9ybeJYLPXlPO0v6zoux5g= MIME-Version: 1.0 Received: by 10.213.77.77 with SMTP id f13mr3998686ebk.66.1264685750402; Thu, 28 Jan 2010 05:35:50 -0800 (PST) In-Reply-To: <20100128131832.GX4873@const.bordeaux.inria.fr> References: <20100128125530.GS4873@const.bordeaux.inria.fr> <20100128131832.GX4873@const.bordeaux.inria.fr> Date: Thu, 28 Jan 2010 14:35:50 +0100 Message-ID: Subject: Re: [Caml-list] Ocaml implementation and low level details From: Konstantin Tcholokachvili To: Samuel Thibault Cc: caml-list@yquem.inria.fr Content-Type: multipart/alternative; boundary=00c09f7f9f29e7bff4047e399804 X-Spam: no; 0.00; ocaml:01 thibault:01 thibault:01 0100,:01 browsed:01 ocaml:01 caml-managed:01 iirc:01 -unsafe:01 caml's:01 0100,:01 browsed:01 caml-managed:01 iirc:01 -unsafe:01 --00c09f7f9f29e7bff4047e399804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2010/1/28 Samuel Thibault > Konstantin Tcholokachvili, le Thu 28 Jan 2010 14:10:27 +0100, a =E9crit : > > I browsed the sources of funk OS one year ago, if I remember corectly y= ou > 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 a= s 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 --00c09f7f9f29e7bff4047e399804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2010/1/28 Samuel Thibault <samuel.thibault@inria.f= r>
Konstantin Tcholokachvili, le Thu 28 Jan 2010 14:10:27 +0100, a =E9crit :
> 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 cou= rse for
page tables you can not allocate them in the garbage-collected area.

> - Also need I disable Ocaml theading subsystem? (Obviously yes, but ar= e there
> some limitations?)

IIRC we just needed to port it.

OK but as th= ere is a giant lock (as I heard), I'm afraid that the multithreading su= bsystem 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?
=A0

> 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. =A0Now 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?=
=A0

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 :/

=A0

Samuel


Konstantin Tcholokachvili
--00c09f7f9f29e7bff4047e399804--