OSDev.org

Can't say i understand that completely. Could you explain that in detail

Let's say you have a stack of a grand max of N frames:

Let's also say you have a bitmap that covers your whole memory (M frames, with M >> N). For quicker operations, frames allocation and freeing go through the stack, but you also have some 'monitoring' of the stack's usage so that:

• when framestacktop<N/4, you wake up a background thread that will sweep the bitmap, searching for free frames, inserting them in the stack and marking them 'used' in the bitmap.
• when framestacktop>N/2, you stop the 'background stack fill' operation.
• when framestacktop>N*3/4, you wake up a background thread that pops frames from the stack and return them to the bitmap, until framestacktop<N/2 again ...

I just wanted to know if the following code is doing what i think it is. Well i thinks its mapping the first 4MB onto itself and Mapping the first 4MB of 3GB onto the First 4MB of RAM. Is this right? I know this code is very badly written but i just wanted to see if it works. the code seems to work fine until i call my print function. It then causes a page fault at address '0xc0002210'(this is the value in cr2 anyway when it crashes). Any ideas why?

i just realised that my entire understanding of Paging is wrong. Well this is the first time i trying it and should'nt have tried it so late at night(about 3AM). Well i don't know what is wrong here, could any of you tell me what is wrong here
Consider the example of accessing a byte at virtual address 0xC000_220A(with paging enabled)
The page Directory is set up at 0x9C000 this means that to access 0xC000 i need an entry at 0x9CC00(right?)
1) Ok now the CPU looks up at 0x9CC000 and gets the dword 0x9D000 (this is setup previously)
2) It then looks up the 2nd entry in 0x9D000 i.e 0x9D002
3) Next it sees that 0x9D002 points to physical address 0x0
After this i dont understand how it computes that 0xC000_220A is actually 0x10220A (because i keep getting 0x20A)
Can anyone explain the right way it happens

I got it at last (what a dumbo i was all this time i was mapping 3GB onto 0MB-4MB physical instead of 1MB-5MB) however now my idt entries do no get called (the system crashes with them) I know its something wrong with the IDT setup function but can't find out where. Can any of you find anything wrong here.
The SetupIDT() function calls the loadInterrupt() for each handler,

this is called with something like this for each handler

and my IDT descriptor is as follows

I want the IDT to be located at 0x500. On running this code the BOCHS output shows the idtr.base=0x500, limit=0x7ff
but as soon as i press a key it triple faults.

I'm using a linked list now, where each item it within an array with one element per page. So you can have random access through the array, or "fast-I-don't-care-about-the-address" access from either end. You can store other stuff there: each array element/list item has prev/next pointers, flags, and a pointer to a VM area object plus an offset within that. Clever use of unions reduces the space needed: prev/next are only needed when the page is in a free list, and the VM stuff is only needed when the page is allocated.

How about using a bitmap-like structure that also allows you to administer the entire memory usage structure? Freeing a process would be traversing a list of pages it uses, setting their state to free and then attaching it to the end of the freelist. Seems like a quick way to do it...

Only wastes like 8 bytes / 4k page or 0.2%

Well i got it working at last. i realised that i was dividing instead of multiplying(real dumb huh?).
Anyway right now i just want to know if these steps which i am following currently are correct(Your comments are also welcome)
0) Link the kernel at 3GB and load at 1MB
1) Disable IRQ's
2) Remap the PIC's
3) Initialize paging
-- Map the first 4MB onto itself(using a 4KB PageTable)
-- Map the first 4MB of 3GB onto first 1-5MB(using another 4KB PageTable next to previous)
-- Map the last entry of PDE into itself(I'm not sure how we access the PDE yet. any explanations?)
-- Point the first entry of PDE to first PTE
-- Point the 0xC00'th entry of PDE to next PTE
-- Load the PageDirectory in CR3
-- Enable Paging
We are now running with Paging
4) Initialize the Low Level Memory manager
-- Determine bitmap size for RAM given by bootloader
-- Setup the bitmap at end of kernel
-- Allocate the pages for kernel by marking the bits(I've marked the entire first 1MB as kernel as the PDE,PTE's stack etc are located here)
5) Setup the IDT with the handlers (I've used a fixed base address 0x500 for the IDT. Is this okay?)
6) Initialize timer etc..
7) Enable IRQ's
Display some info and loop.

Now i have'nt written a memory mapping function because i don't know what exactly to do to map virtual and physical addresses. Should i use new Page tables etc??
I read somewhere that the first 4MB should be unmapped from itself after Enabling paging. Is this correct? If so then how do i access the interrupt handlers etc(IDT is at 0x500)??
Also if i want to map video mem onto 0xF000_0000(as in Mobius) what are the exact steps to be followed?
Last of all could someone explain the math & use behind mapping the PDE into itself.

Err.. some replies would be nice.

Hmmm ... (trying some tutor mode for inpatient people ... [sarcasm]sorry for having to earn a living [/sarcasm])

The math with mapping the PDE to itself ... hehe, this one is nice. I found out by some hours of experimenting that and why it runs well this thing: It is easy:

The pagedirectory is a pagetable. you enter it's adress at index 0x3ff -> thus putting it at the end of the adress space.

If you add a pagetable, you enter it in this pagedirectory. You want to access the pagetable: you take adress 0xffc00000 as the startadress of your pagetables(it is the LAST 4 mb of adress space i remember vaguely). The mmu peeks into the pagedirectory, finds "ah, there is a Pagetable present at this index" and fetches the desired physical adress you want to have - the place where you have to put your pagetables to (say PDE(x)=ptabadress|0x07) - by indexing once again into the pagedirectory, but this time it is the relevant pagetable. since the mmu cares **** about what kind of pagetables is thrown to it's claws, it is very happy to receive the pagedirectory again.

Not much math's explanation of course. there are some explanations about it by Tim Robinson and Pype hanging around. If you've searched keen enough, you'd have found them. The two of them can explain this math stuff way better than me.

Homework: at which adress you will find the pagedirectory? (tip: for this, it won't map INTO the pagedirectory itself like for finding a pagetable ...)

stay safe

Thanks a lot BI. What about the other steps are they right? anyone?

Coming from the ideas of Candy and Pype.Clicker....

Just have a bitmap that maps all of memory, and a cache (buffer/table) that has maybe 128 pointers to free blocks (indexes into the bitmap). Along with each pointer in the cache, there must be a flag that says whether or not its been used before (ie, it may be fragmented). There must also be a pointer (index into bitmap) of the next free block (after the last allocation) in the bitmap.

This procedure completely irradicates all Fragmentation of memory and makes it very fast to get free pages.

when allocating: Take the first page on the cache (or N pages) and use those.
->If the "previously used" flag is set for that page, then set the bit in the bitmap and return the page. If the cache is running dangerously low, then take the page marked by the "next free page" pointer into the cache (at the end) and clear the "previously used" flag. Increment the pointer if you do. We dont always bring a new, unused page in because if we then free a bunch of pages, there wont be room for them in the cache. (should the cache expand?)
->If the flag is not set, Return it as the page, and load the "next free page" page at the end of the cache, and increment the pointer.

When deallocating:
Add the page to the BEGINNING of the list, with it's "previously used" flag set.

I dont see why u need the bitmap at all. You could just use indexes into bitmap that wasnt really there, and just make the cache completely expandable. I guess this sort of turns into the stack method of allocation, but correct me if im wrong.