sharpos-developers

[SharpOS Developers] Roadmap Proposal

[William L. <xfu...@gm...>]

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. I've been meaning to get
feedback on this idea, so I figured a proposal would be a good way to
incite some words on whether this is a good plan. So: my proposal
follows:

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++.

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?

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.

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.

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)

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.

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!!

-- 
fury

long name: William Lahti
handle :: fury
freenode :: xfury
blog :: http://xfurious.blogspot.com/

Re: [SharpOS Developers] Roadmap Proposal

[William L. <xfu...@gm...>]

Wow no one has any comments then? :-P

On 7/27/07, William Lahti <xfu...@gm...> 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. I've been meaning to get
> feedback on this idea, so I figured a proposal would be a good way to
> incite some words on whether this is a good plan. So: my proposal
> follows:
>
> 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++.
>
> 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?
>
> 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.
>
> 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.
>
> 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)
>
> 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.
>
> 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!!
>
> --
> fury
>
> long name: William Lahti
> handle :: fury
> freenode :: xfury
> blog :: http://xfurious.blogspot.com/
>


-- 
fury

long name: William Lahti
handle :: fury
freenode :: xfury
blog :: http://xfurious.blogspot.com/

Re: [SharpOS Developers] Roadmap Proposal

[William L. <xfu...@gm...>]

After discussions about the porting methods we'll use to bring the AOT
to the ARM (and other) architectures, I wish to change my proposal so
that there is another milestone between 4 and 5, where we integrate a
set of scripts to generate the processor's instruction set. Chriss
used a set of custom scripts to extract the instructions from HTML,
we're looking at either an XML-based [iron]python script solution or
one that uses the disops python project (or a combination of both).
The milestone would be:

Milestone 5: A stable system to generate C# code necessary for
multiple instruction sets, used in porting the AOT to other
architectures

On 7/28/07, William Lahti <xfu...@gm...> wrote:
> Wow no one has any comments then? :-P
>
> On 7/27/07, William Lahti <xfu...@gm...> 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. I've been meaning to get
> > feedback on this idea, so I figured a proposal would be a good way to
> > incite some words on whether this is a good plan. So: my proposal
> > follows:
> >
> > 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++.
> >
> > 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?
> >
> > 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.
> >
> > 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.
> >
> > 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)
> >
> > 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.
> >
> > 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!!
> >
> > --
> > fury
> >
> > long name: William Lahti
> > handle :: fury
> > freenode :: xfury
> > blog :: http://xfurious.blogspot.com/
> >
>
>
> --
> fury
>
> long name: William Lahti
> handle :: fury
> freenode :: xfury
> blog :: http://xfurious.blogspot.com/
>


-- 
fury

long name: William Lahti
handle :: fury
freenode :: xfury
blog :: http://xfurious.blogspot.com/

Re: [SharpOS Developers] Roadmap Proposal

[Bruce <ill...@gm...>]

About time I exercised some brain cells, and attempt to process your e-mail
and respond to it.

On 7/27/07, William Lahti <xfu...@gm...> 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.

Re: [SharpOS Developers] Roadmap Proposal

[William L. <xfu...@gm...>]

On 8/4/07, Bruce <ill...@gm...> wrote:
> About time I exercised some brain cells, and attempt to process your e-mail
> and respond to it.

Cool!

> On 7/27/07, William Lahti <xfu...@gm...> 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.

Definitely.

> > 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.

Considering I've gone and broken the console support in the kernel,
I'll have to run down the current ability of the code (provided the
AOT kicks in for it):

- echoes characters to the screen :)
- enter makes a newline
- supports any keyboard type as long as someone made a .skm file that
describes it (just US.skm right now, but I hope to add more)
- full US keyboard support -- the US keymap covers all keys
- unicode keymap support -- the keycompiler supports unicode keymap compilation

> > 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?
>   oing:
> 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.

[AOTAttr.Runtime.ConstructObject]
public unsafe static void ** ConstructObject (uint typeCode, void *parameters);

> 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.

The AOT would read/write heap-type references as void** (pointer to a
pointer). They are void** because the heap is allowed to reorganize
the location of data. When the GC runs, it would ask the runtime to
walk the object tree from the roots. The runtime uses type metadata
included in the kernel to determine the layout of data in the managed
object's memory buffer. In this way, references (at least for EDC
code) are really just 2-level pointers

> 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.

Hmm...

> 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.

Aye.

> > 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.

Later in IRC we figured we didn't need to duplicate mscorlib, only the
korlib that sits in the kernel :-D. This means the amount of
synchronization we have to do is limited to the portions we use in the
kernel. I also came up with the idea of importing the interesting
parts of mono's mscorlib into our repository as a base, then creating
a branch from it with the korlib changes. We could then pump the new
versions of files we use into that 'clean' branch and do branch
syncing in korlib. We might be able to automate this too :-D

> 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.

I'd love to do that. It's theoretically possible, but Chriss would
have to help :-)

> > 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".

I think we could swap m3 and m4 and it would make sense. The korlib is
_not_ necessary for running EDC code. It is only necessary to provide
functionality. You can compile executables that do not use mscorlib
and this I think is where we'll take the kernel core (unmanaged part
included). Once korlib is working, we can compile against that as a
more realistic expectation of the environment inside the AOT. I
believe we'll be able to have the unmanaged parts use static korlib
functionality as well (so it wouldn't just be the stick to measure the
kernel's AOT compatibility). So basically, we'd link
SharpOS.Kernel.dll against korlib instead of mscorlib.

> > 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...

Hrm, I think what I mean is partially AOTed, partially JITed solution,
but it could be possible to just load and JIT the scheduler from disk
and give it control (it would link to SharpOS.Kernel.dll :-)

> > 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.

:-D

>
> > 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.

We can get by past milestone 8, but your right, we'll need driver
interfaces and the like.

Milestone 9
Design and create interfaces for drivers and user applications. The
driver interfaces should provide the ability to create and destroy
memory pages, buffers, DMA buffers, and register interrupt handlers.
The JIT should be able to link InternalCall stubs to a number of
kernel functions that have been exported outside of the kernel core.

> -------------------------------------------------------------------------
> 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
> Sha...@li...
> https://lists.sourceforge.net/lists/listinfo/sharpos-developers
>
>


-- 
fury

long name: William Lahti
handle :: fury
freenode :: xfury
blog :: http://xfurious.blogspot.com/