Menu
▾
▴
sharpos-developers
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(29) |
Aug
(214) |
Sep
(148) |
Oct
(7) |
Nov
(117) |
Dec
(220) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(202) |
Feb
(96) |
Mar
(106) |
Apr
(90) |
May
(10) |
Jun
(13) |
Jul
(99) |
Aug
(76) |
Sep
(17) |
Oct
(6) |
Nov
|
Dec
(1) |
| 2009 |
Jan
(1) |
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2011 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 14:52:31
|
> on writing the design specs for my CLR-based OS, which I named Ensemble > (I'm the author of that "400-page" paper, which is more really like 20 Is it available somewhere for reading? > time, there have been appropriately "popular" FooOSs, such as AmigaOS, > BeOS, and of course MacOS. However, none of those were really well > marketed in the general public sense, save maybe MacOS. But even then, > people are more inclined in the marketing sense to the Apple name, > rather than the MacOS name. MacOS became popular as a side-effect of Mac etc at least arent tied to what its made in. A "disconnected" name in fact is easier. > But who knows whether anyone wants to dig this argument back up. How many active people do we have here? How is the team structured? How are disputes resolved? Are there formal rules for such things? |
|
From: Scott B. <sb...@me...> - 2007-08-28 14:44:00
|
I have previously brought up this topic when I first joined about two months ago. We essentially agreed to disagree. Previously, I was working on writing the design specs for my CLR-based OS, which I named Ensemble (I'm the author of that "400-page" paper, which is more really like 20 something. And it was written two years ago as a final-semester independent research project right before graduation). While I'm a software guy, I have a heavy musical background, and Ensemble seemed an appropriate name (microkernel, where multiple different pieces are working together). I, too, disagree with the FooOS type naming scheme. As was argued at the time, there have been appropriately "popular" FooOSs, such as AmigaOS, BeOS, and of course MacOS. However, none of those were really well marketed in the general public sense, save maybe MacOS. But even then, people are more inclined in the marketing sense to the Apple name, rather than the MacOS name. MacOS became popular as a side-effect of the Apple branding popularity. But who knows whether anyone wants to dig this argument back up. --S Chad Z. Hower aka Kudzu wrote: > Ok pulled down the SVN tree. ISP is playing around with connection today so > it took some time after some resets. > > Anyways... I have a few issues and suspicions but will try to dig for myself > first before bothering you guys. But the first thing I'd like to bring up > for discussion... > > The name SharpOS. I think that as a name itself its ok. But I think there > are some issues with it. > > 1) Is this OS really tied to C#? Or IMO its more .NET. So SharpOS is a > misnomer. NETOS, or ILOS would be more appropriate. Granted I don't like > either one, but I have presented them as an example. CLROS is best of my > initial ideas. But point is moot because of point #2. > > 2) I don't think it makes sense to name an OS based on what it is written > in. Should Windows be COS? Linux CPPOS (granted its kernel is C, not C++), > etc... I think its better to name it after its goals, or something the OS > identifies with or does. DOS was clear - managing disks. Windows is clear. > Linux is clear (Linus Unix). > > As far as what to name it - well I have some ideas what I would name it, but > it depends if you guys have clear goals besides just making a .NET/IL/CLR > based system. Aside from running on managed code - what are your goals? > > Im not trying to rock the boat here, but I think its worth discussion. > > -- > Chad Z. Hower aka Kudzu > "Programming is an art form that fights back" > http://www.KudzuWorld.com/ > http://www.Woo-Hoo.net/ > http://www.DelphiToDotNet.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 > Sha...@li... > https://lists.sourceforge.net/lists/listinfo/sharpos-developers > |
|
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-28 14:30:12
|
Ok pulled down the SVN tree. ISP is playing around with connection today so it took some time after some resets. Anyways... I have a few issues and suspicions but will try to dig for myself first before bothering you guys. But the first thing I'd like to bring up for discussion... The name SharpOS. I think that as a name itself its ok. But I think there are some issues with it. 1) Is this OS really tied to C#? Or IMO its more .NET. So SharpOS is a misnomer. NETOS, or ILOS would be more appropriate. Granted I don't like either one, but I have presented them as an example. CLROS is best of my initial ideas. But point is moot because of point #2. 2) I don't think it makes sense to name an OS based on what it is written in. Should Windows be COS? Linux CPPOS (granted its kernel is C, not C++), etc... I think its better to name it after its goals, or something the OS identifies with or does. DOS was clear - managing disks. Windows is clear. Linux is clear (Linus Unix). As far as what to name it - well I have some ideas what I would name it, but it depends if you guys have clear goals besides just making a .NET/IL/CLR based system. Aside from running on managed code - what are your goals? Im not trying to rock the boat here, but I think its worth discussion. -- Chad Z. Hower aka Kudzu "Programming is an art form that fights back" http://www.KudzuWorld.com/ http://www.Woo-Hoo.net/ http://www.DelphiToDotNet.com/ |
|
From: Sander v. R. <san...@gm...> - 2007-08-28 14:09:53
|
I've been working at a client the last month and things have been way too busy for me to contribute to sharpos.. (or give enough attention to my family) but from next week on (i hope) i'll have more time to spend on sharpos once again. (and my family ;)) I noticed the complete overhaul in the repository.. wow, lots of changes looks good :) too bad it doesn't run too well tough :-/ but i guess that will be fixed soon.. I spend a little time on sharpws, cleaned things a bit up so that it actually compiles ;) still doesn't run tough. I was thinking tough.. right now sharpws has a library called sharpws and an executable called sharpws-server.. now it's not entirely clear, but it looks like the library has some client and common code.. maybe it's better to have 3 parts instead of 2; the client, the server and the host. The host is basically the actuall machine, the hardware if you will.. here are all the things that the client / server have in common and where they get all their resources from. The client and server parts only handle the protocol part of it all basically. This way it should also be simpler to have multiple servers and multiple clients, which could be usefull at some point. I'm also really concerned about font rendering, i did a bit of research into it a while ago and to say it's complicated is an understatement.. it's a whole research field on it's own! I think it's best to use bitmapped fonts for a while, and maybe eventually try to port (eek!) something like freetype to get proper font rendering working.. Also, i looked at the keymapping part and i realized that besides numlock mode is basically more or less the same (from a keymapping pov) as capslock mode. Also, the meanings of some keys are also different when you press ctrl, like pause/break etc. Which just makes me feel that key maps might need to be more flexible and handle as much 'modes' as they need. I haven't put much tought in it tough, just made the observation. I'm sure you all the papers on singularity, they have some interesting ideas on having driver manifests that define which ports/irq/dma's etc. the drivers use.. Which helps automatically check at install time if drivers would have conflicts, and helps port/irq/dma resource management.. Shouldn't be too hard to implement something simular using stubs and attributes.. |
|
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-27 23:12:08
|
Ok great. I have several TechEd's and other conferences in the next month, but Ill try to get to it soon and send my thoughts. Where is everyone located? -- Chad Z. Hower aka Kudzu "Programming is an art form that fights back" http://www.KudzuWorld.com/ http://www.Woo-Hoo.net/ http://www.DelphiToDotNet.com/ > -----Original Message----- > From: sha...@li... [mailto:sharpos- > dev...@li...] On Behalf Of William Lahti > Sent: Tuesday, August 28, 2007 3:06 AM > To: sha...@li... > Subject: Re: [SharpOS Developers] Welcome to the "SharpOS-Developers" > mailing list > > On 8/27/07, Chad Z. Hower aka Kudzu <Ch...@ho...> wrote: > > > The basic goal behind SharpOS is to produce a functional operating > > > system using as much C# as possible and as little C/C++ as > possible. > > > So far we've not had to make any C code, and assembler-level > > > programming is available via a stub class (delegated into so-called > > > Arch-Dependent-Code (ADC) layers). > > > > How open are you guys to changes? I haven't reviewed it yet - it > certainly > > seems inline with my thinking.. > > Oh yeah we're open to changes. It's still very early. Naturally you'll > have to justify the changes with the other active people who are > working on it, but more than likely those ideas are good ones and > we'll be happy with them. We've already got one guy with a 400 page > design paper that he did about this kind of project and although that > definitely influences our work, it won't dominate it. Now is a good > time to voice your opinion, as we are certainly still early in the > project. > > We usually meet around #sharpos at freenode. If you want to hash some > ideas with us, either here or there is fine. > > > But if say I review it, and find things worth discussing, are we > still > > pretty much jello or are we more solid? For my background you can > check some > > links below, or just Google me. > > Not sure how to form the metaphor, but if you mean being flexible in > changes, of course. And of course we welcome feedback :) > > > > > -- > > Chad Z. Hower aka Kudzu > > "Programming is an art form that fights back" > > http://www.KudzuWorld.com/ > > http://www.Woo-Hoo.net/ > > http://www.DelphiToDotNet.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 > > Sha...@li... > > 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 > Sha...@li... > https://lists.sourceforge.net/lists/listinfo/sharpos-developers |
|
From: William L. <xfu...@gm...> - 2007-08-27 23:06:12
|
On 8/27/07, Chad Z. Hower aka Kudzu <Ch...@ho...> wrote: > > The basic goal behind SharpOS is to produce a functional operating > > system using as much C# as possible and as little C/C++ as possible. > > So far we've not had to make any C code, and assembler-level > > programming is available via a stub class (delegated into so-called > > Arch-Dependent-Code (ADC) layers). > > How open are you guys to changes? I haven't reviewed it yet - it certainly > seems inline with my thinking.. Oh yeah we're open to changes. It's still very early. Naturally you'll have to justify the changes with the other active people who are working on it, but more than likely those ideas are good ones and we'll be happy with them. We've already got one guy with a 400 page design paper that he did about this kind of project and although that definitely influences our work, it won't dominate it. Now is a good time to voice your opinion, as we are certainly still early in the project. We usually meet around #sharpos at freenode. If you want to hash some ideas with us, either here or there is fine. > But if say I review it, and find things worth discussing, are we still > pretty much jello or are we more solid? For my background you can check some > links below, or just Google me. Not sure how to form the metaphor, but if you mean being flexible in changes, of course. And of course we welcome feedback :) > > -- > Chad Z. Hower aka Kudzu > "Programming is an art form that fights back" > http://www.KudzuWorld.com/ > http://www.Woo-Hoo.net/ > http://www.DelphiToDotNet.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 > Sha...@li... > https://lists.sourceforge.net/lists/listinfo/sharpos-developers > -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ |
|
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-27 22:56:06
|
> The basic goal behind SharpOS is to produce a functional operating > system using as much C# as possible and as little C/C++ as possible. > So far we've not had to make any C code, and assembler-level > programming is available via a stub class (delegated into so-called > Arch-Dependent-Code (ADC) layers). How open are you guys to changes? I haven't reviewed it yet - it certainly seems inline with my thinking.. But if say I review it, and find things worth discussing, are we still pretty much jello or are we more solid? For my background you can check some links below, or just Google me. -- Chad Z. Hower aka Kudzu "Programming is an art form that fights back" http://www.KudzuWorld.com/ http://www.Woo-Hoo.net/ http://www.DelphiToDotNet.com/ |
|
From: William L. <xfu...@gm...> - 2007-08-27 22:48:09
|
On 8/27/07, Chad Z. Hower aka Kudzu <Ch...@ho...> wrote: > How active are you guys? :) > > Ive been pondering such a project for quite some time now. Im interested > more in this project and if it fits within certain design goals. The basic goal behind SharpOS is to produce a functional operating system using as much C# as possible and as little C/C++ as possible. So far we've not had to make any C code, and assembler-level programming is available via a stub class (delegated into so-called Arch-Dependent-Code (ADC) layers). We've been pretty active recently, although in the last few days things have slowed a bit since I still don't have internet at my new apartment (coming Wednesday :) and I believe Chriss has been doing something else he has to do as well. But we've been really busy working on both the AOT compiler and kernel which is available in our SVN repository. Chriss (Mircea Cristian Racasan, lead dev of the AOT) is currently pretty much rewriting the AOT so it will be capable of being easily expanded to feasibly allow managed code provided unsafe implementations of runtime facilities are available. In the mean time, I've been working on the kernel to bring it up to our Milestone 0.0.1, which calls for a basic kernel with a low level console and some commands for looking around at things. Some AOT problems have blocked it, so it's still a tough road but we're getting much closer (can't wait for the new AOT stuff :-D). The kernel is functional now, with some obvious bugs (console support is currently broken). Paging code exists but it triple faults (disabled atm), and the memory management code has been waiting for paging, but I decided that once I get back in the ring, so to speak, I'm going to get that code working and allow paging to be optional (multiboot command-line switch is available). But we need a _lot_ of testing and bugfixing here. A _lot_. I've also been tinkering with a SharpOS Window System, and I've made some prototype code in /sandbox/projects/sharpws or so. It has a lot of cool features though-- it is similar to X but supports pluggable protocols out of the box (and is 100% C#). We've got a page of potential "ubercool" ideas, some of which might be sane enough to make it into code. It's at http://sharpos.sf.net/cgi-bin/trac.cgi/wiki/BlueskyDreams i believe. So that's about it :) > > -- > Chad Z. Hower aka Kudzu > "Programming is an art form that fights back" > http://www.KudzuWorld.com/ > http://www.Woo-Hoo.net/ > http://www.DelphiToDotNet.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 > Sha...@li... > https://lists.sourceforge.net/lists/listinfo/sharpos-developers > -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ |
|
From: Chad Z. H. a. K. <Chad@Hower.org> - 2007-08-27 16:07:12
|
How active are you guys? :) Ive been pondering such a project for quite some time now. Im interested more in this project and if it fits within certain design goals. -- Chad Z. Hower aka Kudzu "Programming is an art form that fights back" http://www.KudzuWorld.com/ http://www.Woo-Hoo.net/ http://www.DelphiToDotNet.com/ |
|
From: William L. <xfu...@gm...> - 2007-08-25 19:23:52
|
Hey, you guys might've noticed I haven't been around in #sharpos, this is because I just recently moved to a new place and I haven't gotten the Internet hooked up yet. I'll be back to SharpOS as soon as that happens, see you then. -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ |
|
From: William L. <xfu...@gm...> - 2007-08-13 08:05:03
|
I was not able to coax Mono into compiling the mini Kernel/korlib that Chriss had set up to support strings -- the compiler just crashed (without -nostdlib). So, I instead spent some time to get our in-repo big corlib compiling. Now that that's done, here's the list of stuff needed to be done before mono users (me) can get korlib into the kernel: - implement dead method/type elimination in the AOT - merge Chriss' System.String code conditionally - update build file to handle building korlib as well as corlib. I figured I'd throw this note up here so that there's some evidence of my plan... I can't wait to be free of Kernel.String... -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ |
|
From: William L. <xfu...@gm...> - 2007-08-10 17:47:07
|
I installed mono 1.2.5 preview to see if it was a mono issue that was
stopping the test kernel from AOTing and now I see that it isn't:
[exec] Processing IR methods...
[exec] Encoding output for `X86' to
`../../build/SharpOS.AOT.Kernel.Tests.bin'...
[exec] Caught exception:
System.Exception: 'Reg0_2__1__U4' not supported.
[exec] at
SharpOS.AOT.X86.AssemblyMethod.MovRegisterOperand
(SharpOS.AOT.X86.R32Type loRegister, SharpOS.AOT.X86.R32Type
hiRegister, SharpOS.AOT.IR.Operands.Operand operand) [0x00000]
[exec] at
SharpOS.AOT.X86.AssemblyMethod.CMP (RelationalType type,
SharpOS.AOT.IR.Operands.Operand first, SharpOS.AOT.IR.Operands.Operand
second, System.String okLabel, System.String errorLabel, System.String
endLabel) [0x00000]
[exec] at
SharpOS.AOT.X86.AssemblyMethod.HandleConditionalJump
(SharpOS.AOT.IR.Block block, SharpOS.AOT.IR.Instructions.Instruction
instruction) [0x00000]
[exec] at
SharpOS.AOT.X86.AssemblyMethod.GetAssemblyCode () [0x00000]
[exec] at
SharpOS.AOT.X86.Assembly.Encode (SharpOS.AOT.IR.Engine engine,
System.String target) [0x00000]
[exec] at SharpOS.AOT.IR.Engine.Run
(IAssembly asm) [0x00000]
[exec] at SharpOS.AOT.IR.Engine.Run () [0x00000]
[exec] at SharpOS.AOT.Compiler.Main
(System.String[] args) [0x00000]
[exec] While encoding the output assembly.
[exec] Method: System.UInt32
SharpOS.Kernel.Tests.CS.BitwiseOperators::CMPSimpleNot()
[exec] in module: (main),
Mvid=c9247679-80aa-473c-bb29-f0491ad58628
[exec] of assembly:
SharpOS.Kernel.Tests.CS, Version=0.0.0.0, Culture=neutral,
PublicKeyToken=null
[exec] loaded from:
../../build/SharpOS.Kernel.Tests.CS.dll
so there.
--
fury
long name: William Lahti
handle :: fury
freenode :: xfury
blog :: http://xfurious.blogspot.com/
|
|
From: William L. <xfu...@gm...> - 2007-08-07 03:48:51
|
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/ |
|
From: Bruce <ill...@gm...> - 2007-08-05 00:55:08
|
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. |
|
From: William L. <xfu...@gm...> - 2007-08-04 13:36:23
|
I wrote some tests for the test kernel yesterday, including tests for lots of casts between data types and pointer dereferencing. All the dereferencing tests fail, which coincides with ticket #2 posted by logicalerror. I've also closed a lot of stale tickets, leaving room for us to open a crapton more to give us some things to do. Feel free to post tickets about issues you know about or enhancements you'd like to see. -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ |
|
From: Scott B. <sb...@me...> - 2007-08-03 13:51:42
|
William Lahti wrote:
> AOT
> - Core
> - Core.Tests
> - Kernel.Tests
> - Main
> Data
> - KeyMaps
> Kernel
> - Core
> - korlib
> References
> - Mono.GetOptions.dll
> - Mono.Cecil.dll
> Tools
> - KernelTestsWrapperGen
> - KeyCompiler
>
> We also plan to store the SharpOS userspace at trunk/Userspace. What
> do you think about this layout? Was the old one better?
>
It's definitely better. Actually, it could go even farther, just so that
"things are in place for the long-term". As most everyone knows that I'm
working on the out-in-left-field parts of the kernel (runtime VM, etc),
my code was already strewn about in odd places here locally. This is
what I had built here:
SharpOS.Compiler
- AOT
- JIT
- ADC
- X86
- PPC
- Optimizers
- IL
SharpOS.Kernel
- ADC
- X86
- Boot: Arch-dependent boot
- Boot.cs (our current Kernel.cs entrypoint)
- Asm: Arch-dependent assembly opcode stubs
- Schedulers
- Memory: Top-level here handles raw memory
- Pagers
- GCs
- SysRun: More or less what is currently known as korlib. This is the
lowest-level runtime needed for the kernel itself
- IPC
SharpOS.Hardware: Hardware drivers
SharpOS.Graphics: Non-hardware graphics layers
- 2D
- OpenGL
SharpOS.Audio
SharpOS.Net: Non-physical network stacks (e.g. everything above OSI
Layer 1 / Physical)
- IPV4
- IPV6
- TCP
- AppleTalk
SharpOS.DSSFS: Data-Storage System / File Systems. Top-level here holds
our VFS layer, common filesystem code, etc
- Ext2
- FAT32
- NTFS
- CDFS
- ZFSCore: The core of Sun ZFS
- DSS: Our native ZFS-based object data storage filesystem
SharpOS.GUI
- Remoting
- Widgets
SharpOS.TextMode
System.*: CLR Base Class Library wrappers into our API
That's the namespace layouts. As you may see, there really isn't much
"userspace vs kernel space" distinction. It's unnecessary, considering
we're a microkernel all running in the same memory protection space. The
"kernel space" is the kernel itself, which doesn't even handles drivers
and such.
For the directory structure, I personally am a fan of individual build
directories (e.g. SharpOS.TextMode\build, SharpOS.TextMode\src, etc
instead of build\SharpOS.TextMode). And I would rather we move the
References directory back into whatever module needed them, or maybe
even start splitting out the References directory into which module
needs them (e.g. References\SharpOS.Compiler). Tests should also be in
their own subdirectory under the module root (e.g. SharpOS.Kernel\Tests).
That's as much as I've come up with for now.
|
|
From: William L. <xfu...@gm...> - 2007-08-02 23:56:20
|
Rumbles continue as we finish rearranging the trunk for a more extensible and organized layout. What started rough has been polished the last few days and we're here at the point where just about everything is back to the point we left it at. Work continues on tweaking the new .csproj files which will do wonders for any VS.NET users who would like to check out the code. Chriss is separating the script generator we used for the test kernel so that it better fits with the capabilities/model of msbuild. Meanwhile me and Bruce have been keeping the nant files tidied up, and he's also been adding nant rules for FXCop, "nant fxcop" from trunk/Kernel/Core. I've gone and added some rules for AOTing the mainline kernel from the buildfile "nant aot" or "nant aot-image". You can provide extra AOT options with `nant aot -D:aot-options="-text-dump"' or so. We split the dual-project SharpOS.AOT directory into AOT/Core and AOT/Main. We moved all the binary reference DLLs into trunk/References. Various other layout changes to better suit moving forward. So here's the layout of trunk/ as of this writing (r309): AOT - Core - Core.Tests - Kernel.Tests - Main Data - KeyMaps Kernel - Core - korlib References - Mono.GetOptions.dll - Mono.Cecil.dll Tools - KernelTestsWrapperGen - KeyCompiler We also plan to store the SharpOS userspace at trunk/Userspace. What do you think about this layout? Was the old one better? -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ |
|
From: Bruce <ill...@gm...> - 2007-08-02 06:50:56
|
Okay, 34, I can't subtract... On 8/2/07, Bruce <ill...@gm...> wrote: > > Hello everyone: > > After 39 commits, the repo structural changes are complete. Obviously, > nothing is final... > > And remember to make a backup to your local working copy before you > 'update' and 'commit' it. It should go smoothly, but worse comes to worse, > you might have to do a fresh check-out, and then drag and drop your modified > files over top of the new checkout. But it shouldn't come to that. > > Next steps: update the CruiseControl.NET cycles, add some sln/csproj > goodness, and maybe throw some FxCop into the mix, so we can start having an > automated process us tell us what bad programmers we all are... ;-P > > -Bruce > |
|
From: Bruce <ill...@gm...> - 2007-08-02 06:40:40
|
Hello everyone: After 39 commits, the repo structural changes are complete. Obviously, nothing is final... And remember to make a backup to your local working copy before you 'update' and 'commit' it. It should go smoothly, but worse comes to worse, you might have to do a fresh check-out, and then drag and drop your modified files over top of the new checkout. But it shouldn't come to that. Next steps: update the CruiseControl.NET cycles, add some sln/csproj goodness, and maybe throw some FxCop into the mix, so we can start having an automated process us tell us what bad programmers we all are... ;-P -Bruce |
|
From: Bruce <ill...@gm...> - 2007-08-02 04:30:45
|
Hello folks: I've talked with xfury, and I think we need to organize /trunk a little better. If you have changes in your local working copy, your SVN client will require an "svn update" on your working copy before you can commit your changes, after the changes I am doing are complete. As I am not sure as to how politely SVN will understand the restructuring, you should make a backup copy of your local working copy, in case your changes won't merge into the trunk. In such case, the trunk can be reverted to its current revision number, 245, and then you can commit your changes, and then we can try /trunk restructuring again. But I seriously doubt it will be a problem. The only hindrance subversion creates, is that every single directory relocation has to be done in its own revision. After all this is done, and I have corrected the NAnt build files, I will send out another notification. -Bruce |
|
From: Darx K. <dar...@gm...> - 2007-07-30 10:30:25
|
Hi That is really a very great idea! And I don't like it now that it stops after the first error and sending the whole report over the serial port sounds like a very great idea! Implementing the serial support would be fun too. :D Chriss. Bruce wrote: > > The test kernel still fails to compile for me. > > > *sigh* I think I'm going to set up a continuous integration system for us. > > Then, anyone that breaks any of the codebase, can get an automated > e-mail telling them what they did! *wink* > > But in all honesty, I am thinking about setting one up. I'm quite fond > of, and familiar with, CruiseControl.NET. > > I think I could set it up on a computer at home, and we can push > reports to SourceForge, (or rather, have SourceForge pull the reports > using a crontab). But I might be wrong... > > And we can set up the test kernel to write test results to the > emulated "serial port", which Bochs et al can direct to a file which > can be parsed. Eh? Eh? > > Any thoughts? > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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 > |
|
From: Bruce <ill...@gm...> - 2007-07-30 01:10:19
|
> > The test kernel still fails to compile for me. *sigh* I think I'm going to set up a continuous integration system for us. Then, anyone that breaks any of the codebase, can get an automated e-mail telling them what they did! *wink* But in all honesty, I am thinking about setting one up. I'm quite fond of, and familiar with, CruiseControl.NET. I think I could set it up on a computer at home, and we can push reports to SourceForge, (or rather, have SourceForge pull the reports using a crontab). But I might be wrong... And we can set up the test kernel to write test results to the emulated "serial port", which Bochs et al can direct to a file which can be parsed. Eh? Eh? Any thoughts? |
|
From: Bruce <ill...@gm...> - 2007-07-30 01:02:53
|
On 7/29/07, Darx Kies <dar...@gm...> wrote:
>
> Hi
>
> The HowTo is really great and I am glad we have it finally. :D
>
> There is only one thing that should be changed and that is the Test Case
> Example.
> The AOT already does some basic constant folding that means that when it
> finds something like 1+2
> then it computes that so the if statement becomes if (3 == 3). Other
> optimizations will come later
> and the whole code can be reduced to "return 1;".
>
> So it would be great if the CMP method calls another one that does the
> test and CMP only compares the result and returns 1 or 0.
> Something like this:
>
> public unsafe static uint Misc2 (uint granularity)
> {
> switch (granularity) {
> case 0:
> return 4096;
> case 1:
> return 131072;
> default:
> return 0xFFFFFFFF;
> }
> }
>
> public unsafe static uint CMPMisc2a ()
> {
> if (Misc2 (0) == 4096)
> return 1;
>
> return 0;
> }
>
> That way there will be no such optimizations and the test will be more
> reliable.
I will ammend the Wiki as soon as I get the chance.
|
|
From: Darx K. <dar...@gm...> - 2007-07-29 18:54:02
|
Hi
I just checked it and it works for me.
What is the error?
What are you using?
Mono or .NET?
And with what parameters do you run the AOT?
Chriss.
William Lahti wrote:
> The test kernel still fails to compile for me.
>
> On 7/29/07, Darx Kies <dar...@gm...> wrote:
>
>> Hi
>>
>> The HowTo is really great and I am glad we have it finally. :D
>>
>> There is only one thing that should be changed and that is the Test Case
>> Example.
>> The AOT already does some basic constant folding that means that when it
>> finds something like 1+2
>> then it computes that so the if statement becomes if (3 == 3). Other
>> optimizations will come later
>> and the whole code can be reduced to "return 1;".
>>
>> So it would be great if the CMP method calls another one that does the
>> test and CMP only compares the result and returns 1 or 0.
>> Something like this:
>>
>> public unsafe static uint Misc2 (uint granularity)
>> {
>> switch (granularity) {
>> case 0:
>> return 4096;
>> case 1:
>> return 131072;
>> default:
>> return 0xFFFFFFFF;
>> }
>> }
>>
>> public unsafe static uint CMPMisc2a ()
>> {
>> if (Misc2 (0) == 4096)
>> return 1;
>>
>> return 0;
>> }
>>
>> That way there will be no such optimizations and the test will be more
>> reliable.
>>
>> Chriss.
>>
>> Bruce wrote:
>>
>>> Hey Ya'll:
>>>
>>> Because the AOT is very massive, a few of us are in agreement that the
>>> AOT needs to be tested as thoroughly as possible.
>>>
>>> I have posted, on the Wiki, a short guide to writing tests for the
>>> AOT:
>>> http://sharpos.sourceforge.net/cgi-bin/trac.cgi/wiki/HowTo%3A%20AOT%20Unit%20Testing
>>> <I%20have%20posted,%20on%20the%20Wiki,%20a%20short%20guide%20to%20writing%20tests%20for%20the%20AOT:%20http://sharpos.sourceforge.net/cgi-bin/trac.cgi/wiki/HowTo%253A%2520AOT%2520Unit%2520Testing>
>>>
>>> The guide does not go into detail as to the granularity of tests, or
>>> the necessity of any particular tests or types of tests - just simply
>>> how a test is written. It can be expanded either by the rest of you
>>> folks, or as suggestions are made I will maintain the article myself.
>>>
>>> -Bruce
>>> aka Illuminus
>>> ------------------------------------------------------------------------
>>>
>>> -------------------------------------------------------------------------
>>> 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
>>>
>>>
>> -------------------------------------------------------------------------
>> 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
>>
>>
>
>
>
|
|
From: William L. <xfu...@gm...> - 2007-07-29 16:17:15
|
The test kernel still fails to compile for me.
On 7/29/07, Darx Kies <dar...@gm...> wrote:
> Hi
>
> The HowTo is really great and I am glad we have it finally. :D
>
> There is only one thing that should be changed and that is the Test Case
> Example.
> The AOT already does some basic constant folding that means that when it
> finds something like 1+2
> then it computes that so the if statement becomes if (3 == 3). Other
> optimizations will come later
> and the whole code can be reduced to "return 1;".
>
> So it would be great if the CMP method calls another one that does the
> test and CMP only compares the result and returns 1 or 0.
> Something like this:
>
> public unsafe static uint Misc2 (uint granularity)
> {
> switch (granularity) {
> case 0:
> return 4096;
> case 1:
> return 131072;
> default:
> return 0xFFFFFFFF;
> }
> }
>
> public unsafe static uint CMPMisc2a ()
> {
> if (Misc2 (0) == 4096)
> return 1;
>
> return 0;
> }
>
> That way there will be no such optimizations and the test will be more
> reliable.
>
> Chriss.
>
> Bruce wrote:
> > Hey Ya'll:
> >
> > Because the AOT is very massive, a few of us are in agreement that the
> > AOT needs to be tested as thoroughly as possible.
> >
> > I have posted, on the Wiki, a short guide to writing tests for the
> > AOT:
> > http://sharpos.sourceforge.net/cgi-bin/trac.cgi/wiki/HowTo%3A%20AOT%20Unit%20Testing
> > <I%20have%20posted,%20on%20the%20Wiki,%20a%20short%20guide%20to%20writing%20tests%20for%20the%20AOT:%20http://sharpos.sourceforge.net/cgi-bin/trac.cgi/wiki/HowTo%253A%2520AOT%2520Unit%2520Testing>
> >
> > The guide does not go into detail as to the granularity of tests, or
> > the necessity of any particular tests or types of tests - just simply
> > how a test is written. It can be expanded either by the rest of you
> > folks, or as suggestions are made I will maintain the article myself.
> >
> > -Bruce
> > aka Illuminus
> > ------------------------------------------------------------------------
> >
> > -------------------------------------------------------------------------
> > 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
> >
>
>
> -------------------------------------------------------------------------
> 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/
|
44 messages has been excluded from this view by a project administrator.