On 8/4/07, Bruce <[EMAIL PROTECTED]> 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 <[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. 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/sharpos-developers > > -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/sharpos-developers
