Very good suggestions!!!
Bruce Markham wrote:
> 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...)
Yes, without a FS in the kernel we cant load anything.
>
>
> 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.
>
> 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.
We could make a pluggable JITter, which would allow someone to create a
specific JITter for their needs.
>
> [...]
>
> 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.
>
> [...]
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.
--
Jonathan Dickinson
-------------------------------------------------------------------------
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
