2010/1/28 Samuel Thibault > 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