Howdy All,
Ok, keeping this thing going, for the last 4 hours, Mike (grover) and I have
been hashing out ideas and direction on the project. We believe we got some
sound direction figured out that we want to layout in front of you all, but
we are going to first spend the next two days getting the report together,
and send it out. If you want to take a look at what we discussed, it is all
on the IRC chat. Feel free to take a look and give us feedback, else in
about two days, we are going to be sending out a direction document asking
you all for you feedback on it, so we get this boat out of hte mud.
That is all for now,
Adam
On Sun, Jul 20, 2008 at 6:59 AM, grover <[EMAIL PROTECTED]> wrote:
> Hi Adam,
>
> First of all my contributions to a document list of memory management
> topics themselves:
>
> Since we probably all agree that x86/x64 are the primary targets, we should
> really study the application notes and manuals from the processor makers:
>
> - Paging:
> - Intel, "TLBs, Paging-Structure Caches, and Their Invalidation",
> Application Note, April 2007
> - Memory Organization
> - Intel, "Intel 64 and IA-32 Architectures Software Developer's Manual
> Volume 1: Basic Architecture", specifically Chapter 3.3 and following
> - Intel, "Intel 64 and IA-32 Architectures Software Developer's Manual
> Volume 3A: System Programming Guide, Part 1", Chapters 2.4, 3, 4,
> 8.4/8.5/8.8, 10
>
> And probably the most important:
>
> - ISO/IEC 23271, "Common Language Infrastructure (CLI) Partition I:
> Concepts and Architecture",Second Edition from 2006-10-01, specifically
> chapter 12.6
>
> Next my wishlist for a TODO-List - working this list in order is preferred,
> but not mandatory. I've most likely missed some things, because this is just
> my PoV.
>
> - We need a roadmap
> - We really need to define a system architecture, how we want things to
> work in the end. I suppose this should be in a Wiki, where we can all edit
> and track changes.
> - We need to define an operation model for x86/x64 specifically - regarding
> memory model, protection boundaries etc.
> - I believe we need to implement really good boot and processor init
> sequences first
> - Since it is 2008, we should be friendly regarding Virtualization
> Extensions - we should be able to run as guests under a Virtual Machine
> Monitor on supporting processors
> - We really need to get Interrupts working, all other approaches just
> consume time without any benefits
> - Some of this is already done, but needs to be documented - sequence
> diagrams would be nice for others to jump in later on - ideally hyperlinked
> to respective source files
> - We need to define a programming model for the core operating system
> - We really need to obey object oriented principles, such as seperation of
> concerns, testability etc.
> - We need to define the APIs of core OS services so we can use them even if
> they're just mocks at first
> - Actually for testability I'd prefer having mock implementations of all
> of these services
> - We need to define and support a runtime execution engine
> - Without availability of proper runtime metadata we're always going to
> beat around the bush and not really get to a point or even use the benefits
> we could gain by the runtime
> (I'll provide a lot in this regard, but I do need support after I've
> implemented as much as I need there.)
> - We need to support exceptions so that we can stop writing a C-style
> operating system in a more advanced language
> - Since we're working on our own native code compiler(s) we need a lot more
> tests there. I don't think we'll every be happy with any compiler if we
> continue the way we're running now.
> - Ideally we'd try to get 100% code coverage here
> - I'd like us to work closely with Ensemble on this. After all we all have
> limited resources. I think we should focus on a common kernel with
> Ensemble/SharpOS being distributions of it.
> - For the JIT we need some people who work on emitting native x86 code from
> the intermediate representation. I REALLY NEED SUPPORT HERE GUYS.
>
> To get to something, we need to do all of the above. It doesn't make sense
> to work on anything more advanced or higher up in layers, unless the
> basement's been built.
>
> I'm going to eat my lunch. I'll be in IRC later on, but I'm still busy
> writing my thesis paper - only about half way through there - and my
> deadline is aproaching closer.
>
> Mike
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> SharpOS-Developers mailing list
> SharpOS-Developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sharpos-developers
>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
