About time I exercised some brain cells, and attempt to process your e-mail
and respond to it.
On 7/27/07, William Lahti <[EMAIL PROTECTED]> wrote:
>
> Our roadmap is lackluster in terms of providing a real sense of
> progress... our first milestone is trivial in comparison to our second
> milestone, and the massive size of it could be enough to stall
> development. While the completion of the AOT is one of our biggest
> priorities as it sets the course for completing our initial nanokernel
> and process system, there are many other steps between that must be
> completed before the AOT can actually produce managed code for the
> kernel. I think we should expand our roadmap with more, smaller,
> milestones that provide a clear and step-by-step plan to bring our
> first fully-functional kernel to release.
And consequently, with plenty of sub-tasks to flesh it all out.
Milestone 1 stays unchanged
> This milestone is a good PR/attraction point because we'll be able to
> offer a download of SharpOS for OS enthusiasts to play with. It will
> be a good time for us to show the world how much we've cut the endless
> loop of the chicken/egg problem of running C# code (of any variety)
> without lower level support code written in a traditional language
> like C/C++.
So we need functioning console read/write code. Okay, I've added a Ticket
for such. A good amount of the code appears to be in place, and I can't wait
to explore what is and isn't there, and hopefully flesh it out with a '
System.Console' style wrapper.
Milestone 2: a functional runtime and kernel testcase system
> The integration of our runtime code into the trunk kernel, preparing
> for subsequent AOT support for managed code. We will model the runtime
> in such a way that makes integration with the AOT's managed code
> support a no-brainer :). This milestone would also call for a new
> testcase system for the kernel internals-- while the
> SharpOS.Kernel.Tests code actually tests the functionality of the AOT,
> this testcase system would stress the real trunk kernel as we've
> written it. I don't have a solid direction on how we would do this...
> any ideas?
For the AOT supporting runtime implementation?
I guess we need to evaluate the type of function calls that need to be
performed, and set them up as AOT stubs. Obviously memory management and
constructors are part of it. We have to figure out how we map, a structure
that represents a relocatable pointer to a managed object, to the managed
object reference being used in the original C# code at hand. Though not
'runtime' related, (but definitely 'runtime' dependent'), I think we could
even possibly get IL exception throwing code, on this level of the kernel,
to call ADC code to generate an exception interrupt.
As far as testing, I say just use conditional compileation to optionally
both include and execute tests. We can't directly strap it to NUnit, but we
could strap it to the end of the boot-sequence when compiled for such. This
is probably the best way to make sure that tests are interacting with our
kernel under the same circumstances as our kernel interacts with our kernel.
Milestone 3: Korlib
> We will need to have a light, kernel-level mscorlib that we've
> tentatively called Korlib up to this point. We should strive to create
> a corlib codebase that can be used both for korlib and the userspace
> mscorlib (via C#/AOT conditional compilation). The korlib does not
> need to be complete, only functional enough to begin running managed
> code in the kernel.
This is definitely the next step. As soon as we can start instatiating
managed objects, (mostly) worry free, we can start importing pieces of
Mono's corlib. Whether we conditionally compile or conditionally AOT, I'm
sure we want to share as much code with Mono's corlib as possible. Even if
we don't... well, we can still use most of their unit tests. But assuming we
*do* want to use our code - we have to consider whether or not we can make
use of code repo diffing to help maintain our branch.
Regardless, I definitely agree that the korlib is not something thats going
to appear overnight. Regardless of whether its conditionally compiled or
conditionally AOTed, we still have to consider what is involved in getting
the AOT to match an entire assembly of our code in the place of the normal
mscorlib. We might have to move to an Errors/Warnings type return results
for the AOT, so that we can get accurate reporting on which parts of the
kernel won't AOT against our korlib.
Milestone 4: Stable AOT support for managed code
> The AOT at this point should be able to generate managed code (aka
> EDC) with help from our kernel runtime.
Technically, anything that would be able to be AOTed against the korlib
could make this requirement seem fullfilled. We need to either flesh out the
amount of differences between milestone 3 and 4, or merge them to something
like "enough of a korlib to have a scheduler" or "enough of a korlib to have
a VM".
Milestone 5: Completion of a partially managed/unmanaged scheduler
> implementation supporting pluggable scheduler plugins (maybe even
> using more than one scheduler plugin at a time for different
> processes?) as well as a process subsystem for
> management/monitoring/destruction of managed processes (from code
> precompiled into the kernel)
How much managed vs "unmanaged"? By managed you mean running in (and
depending on) the VM? I have to think on this one. I'm not sure that any of
the scheduler needs to be unmanaged. I'm going to have to think about this
one, because I'm getting confused by my own implications...
Milestone 6: Cyclic compilation of the AOT engine
> The AOT should now be capable of compiling itself into the kernel
> (as-is). Naturally it's use will be limited since it is not yet
> suitable for use as a JIT engine.
>
> Milestone 5: Stabilization and completion of version 1.0 of our AOT
> compiler
> This would be equivalent to our current milestone 2
>
> Milestone 6: Refactor the AOT so it can be used as a suitable JIT
> engine for the kernel as well as the AOT engine used to compile the
> kernel.
> The title says it all on this one
>
> Milestone 7: Integrate the JIT and have support for loading/JITing IL
> assemblies at kernel runtime, using the process/scheduler code we've
> written.
>
> Milestone 8: An initial release of the SharpOS kernel.
These last several milestones are beautifully seperated, and I don't have
any questions or issues caused by how they are described.
This is mostly off the top of my head, but it does quantify much of
> the work we need to do to in getting a real initial kernel out the
> door. If you have additions/changes i'd love to hear them-- I don't
> really know everything necessary to make a kernel or else I would've
> done it already!!
Hardware? During or after all of these steps? After might be good, but it is
definitely something to consider.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
