OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 9:29 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: What to do with the rest of the pages?
PostPosted: Tue May 02, 2017 10:33 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 22, 2014 1:14 pm
Posts: 65
Location: /bin
Hello everyone!
My kernel is now able to manage physical memory (using a bitmap), I enabled paging and I can also map virtual to physical addresses. I identity-mapped the first 4MB so I can use the video buffer and to prevent anything below 1MB from going crazy and I also mapped my kernel to 3GB. For that, I used two page tables (which are allocated using my physical memory manager). My question is, what do I do with the rest of the virtual memory addresses? Do I identity map them as well?

_________________
"Programming is an art form that fights back."
-Kudzu


Top
 Profile  
 
 Post subject: Re: What to do with the rest of the pages?
PostPosted: Tue May 02, 2017 10:52 am 
Offline
Member
Member

Joined: Sat Nov 07, 2015 3:12 pm
Posts: 145
Think not in pages but in memory regions.
Your kernel and apps will want a stack, heap, and manually mapped regions.
Decide where they should go. Then imagine allocator for them.
Tips :

- stack grows downwards. Many threads = many stacks.
- you can have holes in the heap


Top
 Profile  
 
 Post subject: Re: What to do with the rest of the pages?
PostPosted: Tue May 02, 2017 11:45 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
You map virtual addresses to physical pages as and when you need to use the memory.


Top
 Profile  
 
 Post subject: Re: What to do with the rest of the pages?
PostPosted: Wed May 03, 2017 6:16 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 22, 2014 1:14 pm
Posts: 65
Location: /bin
Until I get to the stage of a heap allocator, or even plan the memory layout, what is the "typical" approach to handle the "free" pages? Let's say that for some reason my kernel starts behaving unexpectedly (happens quite often :lol: ) and overwrites part of the memory it is not supposed to. If the pages are identity-mapped, will it be easier for me to debug? Thank you for your answers!

EDIT: I realize what I am asking might be a little vague and a matter of personal preference but I would appreciate some tips and pointers.

_________________
"Programming is an art form that fights back."
-Kudzu


Top
 Profile  
 
 Post subject: Re: What to do with the rest of the pages?
PostPosted: Wed May 03, 2017 6:55 am 
Offline
Member
Member

Joined: Sun Feb 01, 2009 6:11 am
Posts: 1070
Location: Germany
Pages that you don't intend to use shouldn't be mapped at all. Then accessing them will cause a Page Fault, which is relatively easy to debug.

_________________
Developer of tyndur - community OS of Lowlevel (German)


Top
 Profile  
 
 Post subject: Re: What to do with the rest of the pages?
PostPosted: Wed May 03, 2017 7:04 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

ThisMayWork wrote:
My kernel is now able to manage physical memory (using a bitmap), I enabled paging and I can also map virtual to physical addresses. I identity-mapped the first 4MB so I can use the video buffer and to prevent anything below 1MB from going crazy and I also mapped my kernel to 3GB. For that, I used two page tables (which are allocated using my physical memory manager). My question is, what do I do with the rest of the virtual memory addresses? Do I identity map them as well?


Typically the first thing you do is split virtual address spaces into zones - maybe one huge area for processes (e.g. "user space" from 0x00000000 to 0xBFFFFFFFF) and another huge area for the kernel itself (e.g. "kernel space" from 0xC0000000 to 0xFFFFFFFF).

Then those zones are split into "sub-zones". More specifically; "user space" is split into sub-zones by the process (e.g. into ".text", ".rodata", ".data" and ".bss" by the linker script, and then the remainder used for shared libraries and/or garbage collection and/or malloc/free and/or whatever the process feels like) where how user-space is split up into sub-zones is none of the kernel's concern (kernel only provides functionality that allows a process to do whatever it wants); and kernel space is split into sub-zones by the kernel (e.g. into ".text", ".rodata", ".data" and ".bss" by the kernel's linker script, and then the remainder used for kernel modules and/or garbage collection and/or malloc/free and/or whatever the kernel feels like).

For an example, for my micro-kernels I always use one part of kernel-space (e.g. from 0xFFC00000 to 0xFFFFFFFF) for "recursive mapping" page tables (to make virtual memory management easier), and another (relatively large) part of kernel-space (e.g. from 0xC0000000 to 0xDFFFFFFF) for message buffers (where this "message buffer area" is managed explicitly by my kernel's message handling code).

ThisMayWork wrote:
Until I get to the stage of a heap allocator, or even plan the memory layout, what is the "typical" approach to handle the "free" pages?


Typically, if you have no use for an area of the virtual address space then you leave that area marked as "not present" in page tables, etc; so that if software accesses something it shouldn't it causes a page fault, which increase the chance of detecting bugs (e.g. dodgy pointers, etc).


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot] and 59 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group