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: Darx K. <dar...@gm...> - 2007-07-29 10:33:35
|
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 > |
From: Bruce <ill...@gm...> - 2007-07-29 06:32:53
|
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 |
From: William L. <xfu...@gm...> - 2007-07-28 18:49:14
|
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/ |
From: William L. <xfu...@gm...> - 2007-07-28 16:50:49
|
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/ |
From: Bruce <ill...@gm...> - 2007-07-28 04:59:11
|
On 7/27/07, William Lahti <xfu...@gm...> wrote: > > Hey we're gonna have a meeting/chat/etc tomorrow. All are invited to > talk about whatever the group ends up talking about (and maybe some of > those things i posted last week)! I've got to work tomorrow at 4 PM > EST (20:00 GMT) so I'll be leaving probably before others do but bah > who cares. > > Yeah I know these meetings used to be formalish, but I find we come up > with much better solutions when the format is freer. Aim for 18:30 GMT > (if you can) or 19:30 GMT. I'll be there as soon as I wake up, as > always. > > Oh, and btw if you have an idea of something you want to work on for > the project (that would be _anything_ from the kernel to userspace to > applications even -- any effort is better than idleness), these chats > are a good place to bring it up and get feedback from the rest of the > group as to whether it'll fit with the rest of the stuff. > > And of course, even if you can't make the meeting tomorrow, there's > almost always a few people in ##sharpos to talk to about the project > (I'm there almost all the time, though I could be idle). > > If you're doing development on our SVN repository, AnarkiNet from IRC > has gone ahead and signed us up for the CIA service (http://cia.vc/) > which has a bot that speaks out the recent commits when he sees them. > Until we can hook trac up to our repository, this is a great way to > get SVN change notifications. > > Hope to see you tomorrow!! Have a good evenin! > -- > fury > > long name: William Lahti > handle :: fury > freenode :: xfury > blog :: http://xfurious.blogspot.com/ > > I might not be able to make it, as I am due for work at 18:30 GMT. I know I've made it before, but I have to make sure I don't impact my quality of work. Not to mention, the only way I can get away with IRCing at work is by using one of only a couple freely available CGI based clients, which are unreliable at best. |
From: William L. <xfu...@gm...> - 2007-07-28 01:55:38
|
Hey we're gonna have a meeting/chat/etc tomorrow. All are invited to talk about whatever the group ends up talking about (and maybe some of those things i posted last week)! I've got to work tomorrow at 4 PM EST (20:00 GMT) so I'll be leaving probably before others do but bah who cares. Yeah I know these meetings used to be formalish, but I find we come up with much better solutions when the format is freer. Aim for 18:30 GMT (if you can) or 19:30 GMT. I'll be there as soon as I wake up, as always. Oh, and btw if you have an idea of something you want to work on for the project (that would be _anything_ from the kernel to userspace to applications even -- any effort is better than idleness), these chats are a good place to bring it up and get feedback from the rest of the group as to whether it'll fit with the rest of the stuff. And of course, even if you can't make the meeting tomorrow, there's almost always a few people in ##sharpos to talk to about the project (I'm there almost all the time, though I could be idle). If you're doing development on our SVN repository, AnarkiNet from IRC has gone ahead and signed us up for the CIA service (http://cia.vc/) which has a bot that speaks out the recent commits when he sees them. Until we can hook trac up to our repository, this is a great way to get SVN change notifications. Hope to see you tomorrow!! Have a good evenin! -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ |
From: William L. <xfu...@gm...> - 2007-07-27 18:29:49
|
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/ |
From: William L. <xfu...@gm...> - 2007-07-26 21:48:12
|
Wow, great thanks to Maciej (himek) for bringing all the tickets back! On 7/26/07, William Lahti <xfu...@gm...> wrote: > If you want to do something for SharpOS, maybe you could help copy > over the old tickets onto the new SF.net trac? I've reopened the > sharpos.org trac so we can access the tickets. I couldn't find a > trivial way to copy them en mass, especially since we've now got more > tickets that took over the old numbers. The old tickets are at > > http://sharpos.org/report > > For an example of a converted ticket and how it should look: > > http://sharpos.sourceforge.net/cgi-bin/trac.cgi/ticket/7 > > Just remember to make note of the fact that you copied the ticket from > SF, as well as info about who originally posted it and when. The open > tickets take priority over closed ones of course, but if those can be > brought over, all the better. > > -- > 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/ |
From: William L. <xfu...@gm...> - 2007-07-26 14:05:05
|
If you want to do something for SharpOS, maybe you could help copy over the old tickets onto the new SF.net trac? I've reopened the sharpos.org trac so we can access the tickets. I couldn't find a trivial way to copy them en mass, especially since we've now got more tickets that took over the old numbers. The old tickets are at http://sharpos.org/report For an example of a converted ticket and how it should look: http://sharpos.sourceforge.net/cgi-bin/trac.cgi/ticket/7 Just remember to make note of the fact that you copied the ticket from SF, as well as info about who originally posted it and when. The open tickets take priority over closed ones of course, but if those can be brought over, all the better. -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ |
From: William L. <xfu...@gm...> - 2007-07-24 04:15:34
|
On 7/23/07, Scott Balmos <sb...@me...> wrote: > So much for attending either meeting. Weekend schedules have that way of > changing on a dime... Yeah the second meeting didnt turn out... > As I was talking with William last week (I like using real names rather > than IRC nicks. You get to know people faster that way), I would > advocate a dual license between LGPL (maybe GPL v2, but I'll get that in > a moment) and a commercial license. This gives us the best flexibility > for potential commercial options down the road, while maintaining the > openness that the project wants. So I'd assume we're talking about offering a proprietary-friendly license to those who can't use GPL/LGPL ala mono, as opposed to just releasing it with an option of two licenses? > > I would say LGPL over GPL because of the intended modularity that we > *will* have in the system. For the sake of avoiding confusion, I refer > to the "kernel" as the whole system (JIT compiler, VFS, scheduler, > memory, everything, including the other system-level microkernel > servers). By using LGPL for the whole kernel and system, rather than > just the CLR userspace libraries (the BCL from the CLR spec, corlib, > etc), this allows us to develop "premium" kernel modules that may be > under a different license, or even closed-source. For example, to stem > off another discussion, we could have a standard GC in the open version > of the system, but sell a high-performance or embedded device / low > memory GC module that is closed source. This wouldn't be possible if the > kernel was purely GPL. I agree. I think anything that provides interfaces for pluggable code should be LGPL, and GPL for tools, the kernel core, etc > Further, using LGPL will alleviate grumbling on the part of device > manufacturers writing their own closed drivers. We must accept the > reality that they will want to keep their drivers closed-source. Even > though this doesn't mean much in the CLR bytecode world, where someone > could rather easily reverse-engineer the bytecode. But like Apple DRM, > with a nod and a wink more or less, it's the thought and flexibility > that counts. True... although LGPL does not have any requirements for those who create modules that link to the original code. > Now, for purely commercial interests, like MySQL and others, we can dual > license under a commercial license for those companies who don't want > LGPL at all. This would make most sense in the case of an embedded > device manufacturer who wants to embed a customized version of SharpOS > (some futuristic cable set top box / home media server comes to mind). > Or we could require commercial licensing for general computer > manufacturers who want to load and brand SharpOS on their systems (e.g. > Dell). I agree. > > The big requirement for doing this dual-licensing is that anyone who > contributes to SharpOS must have on file some type of copyright > assignment. MySQL, Trolltech, and others require this, because of their > commercial licensing. If people don't want to sign the assignment, then > we would have to maintain another fork of the OS. Then someone would > have to go back and clean-room reimplement that open code in the > commercial branch. Here's a sticking point, because we don't have a SharpOS organization-- is assignment viable before we even have an organization to stand for the code? Right now all the code in the trunk is (C) SharpOS, which is a non-existent organization. We did include the author names in the right places so we know who actually wrote what code. > I'd be happy to write up a sample assignment paper, as I'm used to it. > But it's important that we get such a large decision out of the way now, > before we get a huge number of commiters. Right, which is why I brought it up :) > Finally, don't quote me on this because I'm not a lawyer (duh), but > remember that copyrights only cover the specific implementation, not the > idea. Thus, and while I'm not directly recommending we do this, you can > look at Linux, BSD, etc code, get the *idea* of what it does (especially > drivers for hard-to-document devices), and then write our own code. We > just can't directly copy and paste. And in reality, we couldn't copy and > paste anyway, since we're using a completely different language / > environment. Of course. We've got a great method of forcing clean room implementation-- as long as no one gets a hold of the Singularity code :-P > Okay, long email number one down... :D I'll let everyone discuss this > before I go on to write the next one > > > ------------------------------------------------------------------------- > 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/ -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ |
From: Scott B. <sb...@me...> - 2007-07-23 13:42:40
|
So much for attending either meeting. Weekend schedules have that way of changing on a dime... As I was talking with William last week (I like using real names rather than IRC nicks. You get to know people faster that way), I would advocate a dual license between LGPL (maybe GPL v2, but I'll get that in a moment) and a commercial license. This gives us the best flexibility for potential commercial options down the road, while maintaining the openness that the project wants. I would say LGPL over GPL because of the intended modularity that we *will* have in the system. For the sake of avoiding confusion, I refer to the "kernel" as the whole system (JIT compiler, VFS, scheduler, memory, everything, including the other system-level microkernel servers). By using LGPL for the whole kernel and system, rather than just the CLR userspace libraries (the BCL from the CLR spec, corlib, etc), this allows us to develop "premium" kernel modules that may be under a different license, or even closed-source. For example, to stem off another discussion, we could have a standard GC in the open version of the system, but sell a high-performance or embedded device / low memory GC module that is closed source. This wouldn't be possible if the kernel was purely GPL. Further, using LGPL will alleviate grumbling on the part of device manufacturers writing their own closed drivers. We must accept the reality that they will want to keep their drivers closed-source. Even though this doesn't mean much in the CLR bytecode world, where someone could rather easily reverse-engineer the bytecode. But like Apple DRM, with a nod and a wink more or less, it's the thought and flexibility that counts. Now, for purely commercial interests, like MySQL and others, we can dual license under a commercial license for those companies who don't want LGPL at all. This would make most sense in the case of an embedded device manufacturer who wants to embed a customized version of SharpOS (some futuristic cable set top box / home media server comes to mind). Or we could require commercial licensing for general computer manufacturers who want to load and brand SharpOS on their systems (e.g. Dell). The big requirement for doing this dual-licensing is that anyone who contributes to SharpOS must have on file some type of copyright assignment. MySQL, Trolltech, and others require this, because of their commercial licensing. If people don't want to sign the assignment, then we would have to maintain another fork of the OS. Then someone would have to go back and clean-room reimplement that open code in the commercial branch. I'd be happy to write up a sample assignment paper, as I'm used to it. But it's important that we get such a large decision out of the way now, before we get a huge number of commiters. Finally, don't quote me on this because I'm not a lawyer (duh), but remember that copyrights only cover the specific implementation, not the idea. Thus, and while I'm not directly recommending we do this, you can look at Linux, BSD, etc code, get the *idea* of what it does (especially drivers for hard-to-document devices), and then write our own code. We just can't directly copy and paste. And in reality, we couldn't copy and paste anyway, since we're using a completely different language / environment. Okay, long email number one down... :D I'll let everyone discuss this before I go on to write the next one. |
From: Maciej J. <him...@o2...> - 2007-07-22 21:30:51
|
Sander van Rossen wrote: > Congrats with your brother ;) Brothers, thanks. > SharpWS stands for Sharp Windows System, it will be a while before > it'll be even close to operational tough... we don't even have > graphics in SharpOS... > ... at least: not yet :) Sweet. Yesterday I was looking to how graphics drivers work in Linux, but don't except nothing good from me... It's the best source (only) for this nfo. It's at times like this when I realize how important the opensourceness is, especially for an OS. A best bet for us is to start with a simple VGA driver and VESA later, then think of the system graphic library... ...Should we port MESA? If so then should we count on GCC-CIL? I'm somehow worried if it would be reliable enough in both performance and functionality for this task... ...Or should we start our own graphics library in C#? It's a BIG engagement! But we like challenges. Don't we? ;) If so, shall we design it so that it stands for GDI+/cairo, pango and OpenGL all in one? IMHO it should be one big library. Well modularized of course, but perfectly integrated too. So we could write our widget system in OGL-like environment with support for hardware graphics, and vice-versa insert widgets, unicode text and stuff easily into multimedia applications. Oh and for media streaming, do you prefer gstreamer or phonon like solution? JK... Actually, we'll end up with a similar topic someday, probably :P > Since i won't be able to attend the meeting, i'll just throw my 2cts > in beforehand on some of the topics. > > > About the whole "GC: use one GC for all SIPs (software-isolated > processes) or one GC per SIP? " thing.. I just happened to see one of Singularity publications, here's a piece of it: <<Unlike Singularity’s segregation of SIPs on disjoint memory pages, other safe language systems have taken the approach of having processes allocate memory from a single, shared heap. Singularity’s design has several advantages. First, it reduces coupling between processes by eliminating the shared memory allocator and garbage collector and by permitting each process to allocate and reclaim its own memory using the techniques that are appropriate. The large number of existing garbage collection algorithms, and experience, suggest that no one garbage collector is appropriate for all systems or applications, so this flexibility helps achieve good system performance [17]. A shared heap and garbage collector constrain the object format and run-time system of every process that uses it. Moreover, these shared facilities are a common point of failure. Second, Singularity’s design facilitates process termination, as the system can simply reclaim entire memory pages, rather than relying on garbage collection to reclaim individual objects.>> As for the last one note also "Singularity’s segregation of SIPs on disjoint memory pages". On the other side, shared GC could be better for small devices. I think they support both though, but I'm not sure. Correct me if I'm wrong. What do you guys think of Singularity's ways of things: SIPs, channels? I'm not well conscious on all this stuff... |
From: Sander v. R. <san...@gm...> - 2007-07-22 11:16:44
|
Since i won't be able to attend the meeting, i'll just throw my 2cts in beforehand on some of the topics. About the whole "GC: use one GC for all SIPs (software-isolated processes) or one GC per SIP? " thing.. One GC per SIP is supposed to be more secure.. if this is really true, then i'd like to know why exactly. Can we work around it? (Would we even want to?) Is one GC per SIP simpler or more complicated? Theoretically having one GC for all SIPs would make it easier to optimize things, and to transfer memory from one process to another (great way to efficiently pass messages between processes)... but would the benefits outweigh whatever downsides we can come up with? Also, I can imagine that one GC for all SIPs would have less overhead then one GC for each SIP (which would have one extra thread for each SIP). On the other hand yesterday it was mentioned that if you have one GC per SIP it would be easier to prioritize the GC because higher priority GC's would have more cpu time, therefore have more cpu time for their garbage collector.. But should priority of a process have anything to do with memory, which is a system wide resource? The garbage collector is basically a resource manager which manages a shared resource between all processes. The process that allocates the most memory would get most of the time of the GC, the other processes wouldn't care as long as they get their requested memory. Also, a higher priority process would be able to request memory from the GC faster compared to a low priority process, simply because a higher priority process can do things faster... So that makes me feel the whole priority thing would work automatically.. Also, afaik (under win32 at least), allocation of memory under a GC is relatively cheap.. it's the cleanup which takes the most time. Actually the garbage collection is a kind of independent thing that doesn't really have much to do with the original process... it's just cleaning up it's mess.. If the GC is 'global' for all SIPs, it wouldn't matter whose mess it's cleaning up, it just sees a lot of objects in several different generations.. All that would matter is that there's enough memory left for all processes that need some memory and that the memory isn't too fragmented.. (and i guess, somehow, magically, avoid cache misses) But to be honest, i don't feel too strongly about one above the other, but i do think we should make a decision about this because of the right reasons, not because it's common practice, because SharpOS changes the rules somewhat because it's managed.. Personally, i suspect ultimatly we have to try both, unless someone comes up with a killer argument why a global GC simply wouldn't work or would be too dangerous (we already know that one GC per SIP would work) In the meantime i think it would be best to have one GC per SIP, for now, because SharpOS isn't developed enough to actually test the difference between a global GC and a local GC. (one per SIP) SharpWS - too bad i won't be able to discuss this in the meeting since this is one of the parts of SharpOS which interests me the most.. :( Kernel - i think we need some sort of client/server driver system framework so we can plugin our 'drivers' into the kernel (even if these drivers are included in the same assembly) It should be extremely lightweight and have only one layer imho. I guess i'll more to say after i read the transcript of the meeting tonight.. |
From: Sander v. R. <san...@gm...> - 2007-07-22 11:13:15
|
Since i won't be able to attend the meeting, i'll just throw my 2cts in beforehand on some of the topics. About the whole "GC: use one GC for all SIPs (software-isolated processes) or one GC per SIP? " thing.. One GC per SIP is supposed to be more secure.. if this is really true, then i'd like to know why exactly. Can we work around it? (Would we even want to?) Is one GC per SIP simpler or more complicated? Theoretically having one GC for all SIPs would make it easier to optimize things, and to transfer memory from one process to another (great way to efficiently pass messages between processes)... but would the benefits outweigh whatever downsides we can come up with? Also, I can imagine that one GC for all SIPs would have less overhead then one GC for each SIP (which would have one extra thread for each SIP). On the other hand yesterday it was mentioned that if you have one GC per SIP it would be easier to prioritize the GC because higher priority GC's would have more cpu time, therefore have more cpu time for their garbage collector.. But should priority of a process have anything to do with memory, which is a system wide resource? The garbage collector is basically a resource manager which manages a shared resource between all processes. The process that allocates the most memory would get most of the time of the GC, the other processes wouldn't care as long as they get their requested memory. Also, a higher priority process would be able to request memory from the GC faster compared to a low priority process, simply because a higher priority process can do things faster... So that makes me feel the whole priority thing would work automatically.. Also, afaik (under win32 at least), allocation of memory under a GC is relatively cheap.. it's the cleanup which takes the most time. Actually the garbage collection is a kind of independent thing that doesn't really have much to do with the original process... it's just cleaning up it's mess.. If the GC is 'global' for all SIPs, it wouldn't matter whose mess it's cleaning up, it just sees a lot of objects in several different generations.. All that would matter is that there's enough memory left for all processes that need some memory and that the memory isn't too fragmented.. (and i guess, somehow, magically, avoid cache misses) But to be honest, i don't feel too strongly about one above the other, but i do think we should make a decision about this because of the right reasons, not because it's common practice, because SharpOS changes the rules somewhat because it's managed.. Personally, i suspect ultimatly we have to try both, unless someone comes up with a killer argument why a global GC simply wouldn't work or would be too dangerous (we already know that one GC per SIP would work) In the meantime i think it would be best to have one GC per SIP, for now, because SharpOS isn't developed enough to actually test the difference between a global GC and a local GC. (one per SIP) SharpWS - too bad i won't be able to discuss this in the meeting since this is one of the parts of SharpOS which interests me the most.. :( Kernel - i think we need some sort of client/server driver system framework so we can plugin our 'drivers' into the kernel (even if these drivers are included in the same assembly) It should be extremely lightweight and have only one layer imho. I guess i'll more to say after i read the transcript of the meeting tonight.. |
From: Maciej J. <him...@o2...> - 2007-07-22 10:12:10
|
Nice to see you're all back. Unfortunately I'm not gonna make it today also, because today's my brothers' birthday ;) I hope I too can be of some use soon. Up 'till now I was just watching your efforts and did nothing. I've seen SharpWS term in the wiki, what does it stand for? William Lahti wrote: > OK, I made a mistake in getting this week's meeting off the ground. As > most of you know, the weekly meetings fell apart between our stays at > sharpos.org and sharpos.sf.net respectively, but now that we're > getting back to work on bringing the first open source operating > system built around the common language infrastructure I figured it'd > be good to have some live discussions on the topic. > > Unfortunately I posted the mail to the wrong list (although niriven > did post the new time on the wiki)... so no one got the mail but me. A > few people made it anyway, so we did talk about a few of the topics I > had in mind. However, to get more input from the sharpos community, we > want to continue the chats tomorrow in the same place, but at 18:30 > GMT, which is 2:30 EST. This will better accommodate those of you in > Europe. Because this meeting is such short notice, I'd like to also > continue discussing these things on the mailing list. So please go > ahead and throw in your change if you have the chance. > > I've posted a list of things to talk about on the wiki at > > http://sharpos.sf.net/cgi-bin/trac.cgi/wiki/IRCMeetings > > I've also posted the transcript (slightly annotated) in the PastMeetings page. > > > |
From: William L. <xfu...@gm...> - 2007-07-22 08:30:33
|
OK, I made a mistake in getting this week's meeting off the ground. As most of you know, the weekly meetings fell apart between our stays at sharpos.org and sharpos.sf.net respectively, but now that we're getting back to work on bringing the first open source operating system built around the common language infrastructure I figured it'd be good to have some live discussions on the topic. Unfortunately I posted the mail to the wrong list (although niriven did post the new time on the wiki)... so no one got the mail but me. A few people made it anyway, so we did talk about a few of the topics I had in mind. However, to get more input from the sharpos community, we want to continue the chats tomorrow in the same place, but at 18:30 GMT, which is 2:30 EST. This will better accommodate those of you in Europe. Because this meeting is such short notice, I'd like to also continue discussing these things on the mailing list. So please go ahead and throw in your change if you have the chance. I've posted a list of things to talk about on the wiki at http://sharpos.sf.net/cgi-bin/trac.cgi/wiki/IRCMeetings I've also posted the transcript (slightly annotated) in the PastMeetings page. -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ |
From: Bruce <ill...@gm...> - 2007-07-21 20:49:16
|
I've been looking into returning to SharpOS, somewhat out of boredom with other pursuits, and also due to intrigue to a new possible pursuit. I'm wondering what it would take to simultaneously support SharpOS on the Nintendo DS as we develop it for PC. The homebrew niche for the Nintendo DS is practically exploding, but good software is still quite a ways off. There *is* Linux for the DS, but no GUI, as the DS has very little RAM and no MMU. Also, no GCC. Therefore, no cute Mono GUI apps are even remotely feasible. So I'm doing some research into the ARM architecture, and the DS specifically. I think it would be cool to try and write a DS-specific ARM backend to the AOT. There are other issues, like no keyboard. And emulating an MMU (for paging purposes, if nothing else) will be slow. But I think it will just challenge the way we look at designing OSes, and the potential is amazing. As far as emulating an MMU being slower for the GUI stuff, I think it will make SharpOS on the DS a horse of a different color, versus the same for another architecture. With limited RAM, and the storage medium (usually flash memory, ala Micro SD and the like, depending on the hardware pass-through being used), it would not be wise to keep too many seperate apps "resident" at the same time. Anywho, I'm still only trying to *think* about the details. But I'm definitely thinking that SharpOS is a better answer than trying to gut and rewrite the Linux kernel to handle the different paradigm. I don't want to suggest SharpOS go in a different direction because of fancy fantasy for a handheld that will be obselete in the next few years - BUT, I do think it presents healthy questions for SharpOS itself (especially in the way of hardware - the DS has no keyboard, two screens, one with touch sensitivity - which in the way of human interface devices, is practically a tablet PC with an extra screen). But there are lots of people with DSes that I think would like to be able to manage contacts and calender info, play music, watch videos, do instant messaging, web surfing, and (depending on the quality of that microphone) VOIP, from the convenience of their pocket, without paying outrageous prices on for next-gen phones. Not to mention the alturistic idea of the potential for extra feedback for SharpOS. ;-) Any thoughts, anyone? |
From: Bruce <ill...@gm...> - 2007-07-21 20:46:21
|
I'm at work, as usual. But I am thinking about taking a dip back into SharpOS. See seperate e-mail for more info... On 7/21/07, William Lahti <xfu...@gm...> wrote: > > We're gathering in the ##sharpos room at IRC-- please come if you can > make it... it was supposed to be 19:30 but not many people showed up. > It's actually now 20:16. Sorry if my fumbling of the US timezones > confused anyone. > > -- > 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-07-21 19:17:00
|
We're gathering in the ##sharpos room at IRC-- please come if you can make it... it was supposed to be 19:30 but not many people showed up. It's actually now 20:16. Sorry if my fumbling of the US timezones confused anyone. -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ |
From: Sander v. R. <san...@gm...> - 2007-07-19 11:43:53
|
In my own version of the trunk i'm using function pointers to transfer timer / keyboard events to my Console class.. (Eventually this will have to be replaced by some event buffer) So now i ran into a problem with the way c# works & the limitations of the AOT compiler.. The problem is; i would like to use a struct as a parameter in my event functions.. But the moment i call the function i need to do: &myStruct .. and C# won't let me do this.. So maybe it would be possible to create an AddressOf stub? Also, right now i have a Call function in my version of the kernel, which i use to execute my function pointer with a parameter.. this way i can simply do Kernel.Call(myFunction, myParam) unfortunatly, i have to make a version of this function for every type of parameter i would us.. which is clumsy.. i would like to use generics (not sure how that would work with the aot).. And altough i can restrict the parameters to be 'struct' (value-type), now all parameters run into the &myStruct problem above... maybe a generic call function stub would be usefull? All in all, it would be nicest if we could just use the delegate syntax in C#, and (with some restrictions obviously) let the AOT sort it out for us.. I'll look at the AOT code to see what i can do, but my time is rather limited.. |
From: Sander v. R. <san...@gm...> - 2007-07-12 07:11:19
|
This morning i was thinking about another advantage of an managed OS over a non-managed OS; Take for example windows.. All windows applications have an event loop, and while the application will actually sleep when it doesn't receive any events, the application actually gets spamed with all kinds of events the application doesn't actually care about... So i was thinking.. with managed applications we have the advantage of having reflection.. The OS could actually figure out which events we're actually using.. In fact if we use the following model; SharpOS.OnKeyUpEvent += MyOnKeyUpDelegate; instead of the standard model; class MyApp : SomeAppBaseClass { public override void OnKeyUp() { ... } } Then it would be dead easy to determine if an application would actually want to receive an event at all.. If we mix all this with double buffering the screen output for applications (in a gui), then most applications will actually only need to execute some code when you click on it (in a gui) or press a key... Which means in between those events the application wouldn't need to have any timeslices from the OS. In fact, we could tell people who would make applications for sharpos to only register (and later unregister) events when you actually need them.. (for example; for a drag/drop operation, register 'onmousemove' after you press a button, and unregister it after you release the mouse button) What do you guys think? Cheers |
From: Sander v. R. <san...@gm...> - 2007-07-11 15:00:14
|
For those who don't know me, i posted some stuff on the wiki under the name 'LogicalError' and i've made some modifications to the trunk. (bug fixes to make the kernel & aot work properly under win32) I just replaced while(true); in kernel.cs to: byte n=0; while (n<100); the first crashes aot, the second one works.. i also started a little bit experimenting with a keyboard hook in my own little trunk.. and not having the ability to make an array, or have any memory management at all is rather limiting to say the least... (right now i hacked in an array using a byte* string) So i was wondering.. what's the current status on that end of the project? I haven't seen any mailing list activity for a while now, is everybody on vacation or something? ;) Also, are there any plans on how to handle the keyboard? I don't want to do work which will turn out to be useless.. I guess we need some sort of event system to pass pressed keys along to applications... which i suppose is not something for the near future? Cheers |
From: William L. <xfu...@gm...> - 2007-07-06 19:50:03
|
All the services have now been moved to SourceForge.net, with the notable lack of our tickets. We've got new milestones in place. I took the liberty of revising our milestone schedule in regards to our first demonstration release which will feature a basic SharpOS kernel with input/output support and a few basic console commands. A few things the commands could do: list-devices -- list automatically detected devices show-log -- show the kernel log kernel-info -- show kernel info, the name, version, and ADC layer / processor compiled for cpu-info -- show CPU info as obtained from the ADC layer More commands could be used to interact with subsystems as we get them running, such as drivers, filesystems, human input, display etc. We could include a small text console game or something as well. Most of this can be reused for a rescue console which we could compile as a separate DLL and "add-in" during AOT compilation, so if you wanted to include support for a rescue console, you would do SharpOS.AOT.exe SharpOS.Kernel.dll SharpOS.RescueConsole.dll And the second milestone is now what used to be our first milestone: completion of the AOT on the X86 platform. Beyond this I haven't set anything up, but I think the logical choice would be to complete an initial version of the real-life functional kernel with a runtime, support for SIP/HIP processes, message passing / buffer IPC, and an API to communicate with the kernel. From there we can start writing applications and drivers for various hardware. What do you all think about the roadmap? Changes, gripes, thoughts in general? -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ |
From: William L. <xfu...@gm...> - 2007-07-06 08:49:43
|
I've finished getting everyone subscribed to the new list at sha...@li...... I'll double check to make sure everyone made it through. You should've gotten a welcome message before this one. if not, resubscribe or email me. Your settings have not been reimported, if you usually make use of digest emails, please visit https://lists.sourceforge.net/lists/listinfo/sharpos-developers to change your settings. Terribly sorry for the inconvenience, mailman (particularly with sf.net's settings) isn't the most migration-friendly software package I've dealt with in the last few days. Many mails that were supposed to be sent to the old list never made it. Hopefully now we can talk about the project again :). As for the rest of the SharpOS migration to SourceForge.net, you can see the trac installation we've got going at http://sharpos.sf.net/cgi-bin/trac.cgi. I've made a prototype web design that you can see at http://sharpos.sf.net/test/. Keep rockin! -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ |