>
> > Init's job is pretty simple. First, it sets up the stack and the
> heap
> > (stack grows downward in memory, heap upward). Next, it mounts the
> > root device as read-only, loads mscorlib into a special place in
> > memory, and then loads the kernel executable into another place in
> > memory. It then sets up any last environment things, and jumps to
> the
> > kernel.
> >
> >
> > I don't understand why you are saying it has to setup a "stack" that
> > is a different thing from the "heap". Is there a specific reason or
> > methodology that I am missing? The term is also confusing because
> > there is already the x86 CPU stack, but I believe you are describing a
> > secondary heap. Regardless, it sounds like you want two
> > point-of-origins for memory allocation. You'll have to elaborate why
> > two specifically, (and not say, just 1 for the kernel, and then 1 for
> > every process or every page of every process.)
> Erm, you do have two memory spaces in .Net. Once for Method-Scoped and
> one for 'Class-Scoped'. That is anything that you create in a method is
> put on the stack, and anything you put in a class that will live for
> longer than a method call is put on the the heap.
Its all semantics. They are both heaps, either way. And where you put them
(and how you allocate them), don't exactly matter much. In the end, its 6 of
one and half a dozen of the other.
>
> > The kernel then has control and has a working stack and heap. It can
> > start loading modules. It can start doing its work.
> >
> >
> > By loading modules - the only thing it can do is read binary data from
> > disk. So unless it is loading AOTed "modules", it can't load anything
> > useful...
> >
> > So I assume the mscorlib it loaded is AOTed?
> >
> > Does this "kernel" that you say "init" loads, have the virtual
> > execution system in it? (That is, does it have the JIT compiler?) We
> > want as little code AOTed as possible. You have to remember that that
> > is the tenet driving most of us here.
> Agreed, as little AOTed code as possible. How about this:
>
> Init Loads -> Reads JITter from HDD -> Continues loading CIL modules.
Its definitely possible, but for now it is certainly easier to have the JIT
in the kernel image. (And it would be harder to manage embedded type
information if you have to load some dynamically without the JIT to do it
correctly - the type information code should be centralized.)
I do have to object to calling the inner part of the kernel, "init". Because
it has alot to do, and "init" is a bit demeaning to its purpose. The kernel
we have now, is still not enough, to constitute what we need to support a
running JIT.
>
>
> We could make a pluggable JITter, which would allow someone to create a
> specific JITter for their needs.
We certainly could, without too much difficulty, eventually. But I feel
sorry for the poor shmuck that wants to write a custom JITter...
>
> >
> > [...]
> >
> > So, I ask you, what's wrong with this picture? I never understood
> the
> > need for a "stripped down" mscorlib.
> >
> The reason we need a stripped down corlib is because the AOT (currently)
> compiles everything in an assembly. So the kernel would get scary big.
>
> Another perspective (I am not 100% clear on the topic) is that the
> korlib is just a convenient way to separate the stubs from the kernel.
Well, like I said - not everything that the default corlib says it can do,
can actually be done at the level of the kernel that we need to write
support for the JITter in. (If you want drivers to be safe, they have to be
JITed, which means they can't be used on a level below the JIT.) So yes, we
did talk about having a watered down corlib, "korlib", that would do what we
need.
In fact, due to our realization that it would be infeasable both in
licensing and in coding work, to take Mono's corlib (or worse, not), and
attempt to code a watered down one - we won't be having a "korlib" per se.
We will implement the stubs that the (compiled) Mono corlib needs. And the
ones that due things that the low-level kernel can't do yet, will just throw
exceptions. And we can write a seperate stub implementation layer, that sits
above the JIT (and is a sibling to the hardware abstraction, authentication
system, etc.) that will implement the remainder of the stubs.
The exact format of stub implementation, and how to marshal the types, is
still being worked out. But it requires a relatively minimal amount of work
versus other proposals, and allows us to leverage the hundreds of thousands
of man hours that have gone into the Mono project - and leverage the ongoing
fruits of their work.
Johann:
I still think xfury, DarxKies, and I, all need clarification on what you are
saying. We went round and round in circles before - with you not quite
understanding us, and us not quite understanding you - and all any of us
kept doing was repeating ourselves. You keep repeating that you think the
kernel ("init") should "load" the AOT and the rest of of the kernel and
assorted modules - but you have yet to elaborate on what you mean by "load".
You've got half of us thinking you want to AOT everything in advance.
Another half of us think you want us to write an interpreter to emulate CIL
execution. And a third half of us thinks you don't understand the
interdependencies between the JIT and the rest of the system. (I know, too
many halves, bare with me...)
The problem is, you've yet to mention "JIT" or "Virtual Execution System" in
any of your posts. You keep saying "load", and then you get quiet when the
rest of us start arguing about what we *think* you are saying.
We are all computer nerds here. We are all rambunctious, opinionated
hermits. (Hermit-ness subject to variation from programmer to programmer.)
Try not to be shy! Speak up! And elaborate!
/end to Johann
>
> > [...]
> Just one thought. What happens to a bad OS? In terms of a broken one?
> Surely we need some AOTted *nix commands to allow the user to rescue the
> system. Just a thought for much later on.
>
Oh well, put it in the bucket. ;-)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
