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?
Paging (again)
Re:Paging (again)
Hi,
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
Sounds good to me...yukito wrote:2 for Allocating and delocating memory (anywhere, no requirements)
2 for allocating and delocating memory for DMA, continuous and below 16MB.
Right?
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.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?
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
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.
Re:Paging (again)
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.
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.