Welcome back! I'm going to try to tackle this piece by piece. Because I
don't think the rest of us have really understood your proposal, and I think
my questions before went unanswered both due to your possible frustration,
as well as an understandable preoccupation with the rest of your life. ;-)
First, our boot loader loads up assembly called init. Init is written
> in C# (doesn't have to be, but it would be nice), and basically only
> has hard coded read-only file system drivers. It's compiled as EIC,
> meaning that the AOT compiler can compile it as simple machine code,
> no dependencies.
Okay, I understand that well enough. A set of hard coded read-only file
system drivers also means it will need the ability to enumerate file storage
devices: floppy, hard disk, USB mass storage, CD/DVD-ROM, etc. (I don't
think any of us here want an EIC-based hardware abstraction...)
> 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.)
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.
Now, sharing libraries. Mscorlib is already in memory, why can't we
> reuse it? We can. When an application needs to access a library, the
> instruction pointer will change to a method of the library, but the
> stack / heap pointers will stay the same.
Sure, sure.
> Later, if we decide to have separate address spaces, we can use paging
> and map where ever those libraries are to a portion of the address
> space.
Most definitely.
So, I ask you, what's wrong with this picture? I never understood the
> need for a "stripped down" mscorlib.
>
Well, I see myself stepping back and asking, where is the heart of what the
OS is about? Where is the JIT?
As far as "stripped down" mscorlib - the mscorlib can't do everything (in
fact, almost nothing) by itself. (And we certainly talked about a stripped
down corlib as part of our effort to seek a solution to having a corlib that
would support the JIT.)
I think we are, at this point, only going to have 1 corlib, and we are just
going to implement the stubs and let the AOT link the corlib to the stub
implementations. To use Mono's corlib, we have to have it AOTed and embedded
in the kernel binary. No "loader" can do this at "init" execution time -
because this is an AOT or a JIT task. And since we have to have the corlib
in memory to run the JIT, that means its an AOT task, right?
So our current idea, which DarxKies is hammering out details for, is to
write a kernel with as much of the corlib stubs implemented as possible, and
the rest tying out to C# written, EDC abstractions, that are also AOTed. The
corlib will be dumped in too, and AOTed. And the JIT will sit on top of all
of it.
The system will have some managed, EDC, still-IL filesystem drivers embedded
in the kernel image that it can load and JIT, and then seek out the rest of
the OS with.
Here is the reasoning:
- We want to favor JITed over AOTed, EDC over EIC, and safe over
unsafe.
- We can't write our own corlib because it would take years, and it
would never be as well-maintained as the mono corlib that already exists and
already has 1000s of people working on. (And we can't use their code as a
base, because of licensing incompatibilities.)
- By the time in kernel boot-up, that the kernel is loading stuff from
disk, the JIT needs to already be in place. We cannot be loading AOTed stuff
on the fly, because then we lose the safety and the power of JITing IL.
So please, write back and explain yourself a little better. I can't tell if
you are suggesting that we AOT everything, or if you just don't understand
the implications that "loading" something is alot different from JITing it.
-------------------------------------------------------------------------
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
