OSDev.org

Hi again,

you haven't heard much of my nagging in the past few days because of the start of the new academic year, but here I am ... again.

Before I start writing the actual paging code - I think I understand it enough to start coding (to START ) However, I was wondering how people solved the DMA problem (needing continous memory <16MB) - What I was thinking was using a bitmap for the lower 16MB and a stack for the rest of the memory, allocating general memory above the 16MB mark first, for performance sake, and when none is left to use the remaining 16MB. So when I work on DMA I can request memory below the 16MB mark, which will be continuous (easier to find with a bitmap). Now maybe it's not the best way to do things, but this is just a learning experience for me anyway. Also, if I use this method, I would need 4 allocating functions:

2 for Allocating and delocating memory (anywhere, no requirements)
2 for allocating and delocating memory for DMA, continuous and below 16MB.

Right?

Are there any other things (PCI, AGP,...) that need memory to be allocated and fullfilling special conditions? Or are they memory mapped like basic VGA output, and need pages to be written write through and at the right virtual & physical addresses? Or am I just incredibly stupid?

Hi,

yukito wrote:2 for Allocating and delocating memory (anywhere, no requirements)
2 for allocating and delocating memory for DMA, continuous and below 16MB.

Right?

Sounds good to me...

yukito wrote:Are there any other things (PCI, AGP,...) that need memory to be allocated and fullfilling special conditions? Or are they memory mapped like basic VGA output, and need pages to be written write through and at the right virtual & physical addresses?

For managing physical RAM that's all you need, although it's always possible to support more (NUMA, page coloring, dirty/clean pages, PAE/64 bit physical addresses, "hot-add" RAM, delayed "free()" for pages recently used for DMA, 4 MB/2 MB page sizes, etc). Most people don't need (or don't want) these things though.

Managing the physical address space and caching is another story entirely - things like deciding the base address that a PCI/AGP card should use for memory mapped I/O and adjusting MTRRs (and/or PAT entries and paging) to suit. This can be (and IMHO should be) left until much later on...


Cheers,

Brendan

Thank you very much!

I wasn't planning on implementing PCI or AGP or I/O with any device just yet, but if there was some special way they want their memory to be allocated, I could as well implement it in my memory manager while I'm writing it instead of changing it when paging has been long forgotten Dirty and clean pages will be used but I'm not sure if it's of much use, if any. 4MB pages will be used for the kernel code and data, and the delayed free() may be implemented when I know something more about DMA, it's only a minor change anyway.