I'm going to be away for a bit, going to China and I don't know when I'll
get internet back. Anyways, for the Memory Management book, the Intel
Pentium Architecture section in Chapter 1 is good. You can also take a look
at the Linux and Windows implementations in Chapter 2. I'm currently
working out how to get the page tables set up before diving into the higher
up allocations. Got some basic code written for the framework, but they're
obviously not ready for committing. Anyways, I expect to see more ideas
when I get back online, so don't stop just because I'm away for a bit.
On Thu, Jul 17, 2008 at 11:44 PM, Adam Stevenson <[EMAIL PROTECTED]>
wrote:
> Howdy Zachary and All,
>
> Yes, I believe that we do need to do a good restructruring. I have a bunch
> of ideas I have been hashing out in my sandbox, but I there are parts that I
> am not sure exactly what is going on (some parts get cryptic, any understand
> the process of preparing the image fully?). I first think we need a high
> level diagram of all the major components, so we can start figuring out
> where we can make plugable modules. From my own project work, and my
> experience with biologcial systems, we need to slowly evolve this and not
> break it. (I know duh).
>
> First does thing support interfaces yet? Because I don't see much of them
> in the code base. If not, I say we work on making a list of abstract
> classes that we can start keying in as modules. I know Grover has been
> working on a lot of this, and we need to get his input on the AOT plugable
> architecture. Anyone going to be around Sunday afternoon (CST) - or most
> anytime Monday (minus 3:00 to 5:00 CST)? I can sit down online with anyone
> and start diagraming some of this stuff and work a bit in team mode -
> identify document, and review. And then we can send out whatever documents
> we get done via the list serve, and continue to move on ot the next. Anyone
> up for it?
>
> As for what I have been working on is a bunch of class processing stuff,
> and memory structuring of components. I want to build an architecture that
> you could say is "fractal" - thus allowing for the same archtiecture whether
> a JIT is being ran on top of a JIT (pretty dang inefficient) or is actaul
> the JIT. To do this, everything needs to be turned into an interface, to
> allow for components to shift up and down. I have started looking into how
> to structure this namespace and working on a prototype base, but it is not
> compable yet (on my to do list for next week). But bottom line, this is
> still a long way off from where the AOT and SharpOS is now, so this is by
> now means a fully workable design that SharpOS can be converted too. Plus
> there are some differences in concepts too with the idea of runtime and OS
> that are going to have to be hashed out.
>
> So personally, we need to look at all of us "newbies' fully understanding
> what we have, and second we slowly turn this thing modular and make a list
> of all the modules and what their requirements are, so the code base can be
> evolved in small parts versus changing one thing causes a bunch of ripple
> effects throughout the code. My guess, a lot of this modularity already
> exists, but we just need to uncover dividing points. So back to Sunday and
> Monday for me. Anyone game? And thoughts on how we want to start breaking
> up this code base into smaller understandable pieces? Oh Zachary, I got
> both those books on Memory Management and Garbage Collection - need to
> finish them, but if you have concepts to reference, just let me know page
> numbers.
>
> Adam Stevenson
>
> Graduate Student
> Department of Biology
> Texas A&M University
> College Station, TX 77843, USA
>
>
> On Wed, Jul 16, 2008 at 10:03 AM, Zachary Gorden <[EMAIL PROTECTED]>
> wrote:
>
>> Just a clarification, when I say memory manager, I mean from the page
>> tables to the physical memory table to the allocations. It seems that
>> people keep confusing what I am referring to whenever I say MM. This is
>> mostly an informational thing to let people know what's going through my
>> head and the fact that I'm not dead and still working/planning.
>>
>> The memory manager as it stands suffers from a somewhat awkward design
>> that makes it difficult to correct certain items. Not exactly anyone's
>> fault, as SharpOS needed a MM and that's what it got. The gist is, trying
>> to fix the issues in here and/or optimizing it won't do much in the long
>> term, which is one reason you guys haven't seen much activity from me.
>>
>> I've been mostly consulting a few ROS developers on how to bootstrap a
>> page table based MM, the initial loading and stuff, so that's the
>> explanation for the lack of code. For the time being, I've gotten most of
>> the conceptual things explained and will be writing out some of my own code
>> as well as examining just what kind of support for paging exists right now.
>> And actually, in the process of trying to look at the current code, another
>> thought occurred to me. Currently, the ADC is, to put it simply, horribly
>> organized. It's basically all of the AD code in one spot, without any
>> actual segmentation. That is definitely going to screw with us down the
>> line, and it is likely to not be limited to the ADC.
>>
>> Because of the above reasons, I am most definitely going to need to create
>> a branch (once I figure out how), as obviously doing surgery on trunk is
>> going to result in incredible instabilities and breakages. But as far as
>> the restructuring goes, I think a lot of us would benefit from such changes,
>> including people already working with their own branches. I'd like to hear
>> from other people on the restructuring idea, as I know I'm not the only one
>> who noticed the issues.
>>
>> -------------------------------------------------------------------------
>> 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
>
>
-------------------------------------------------------------------------
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
