On 1/11/2013 11:19 AM, Adam Kłobukowski wrote:
W dniu 11.01.2013 16:42, Mark Duckworth pisze:
Hi guys,
I really don't know what I'm doing but I am going to make an honest
effort to attempt to implement kernel support for virtual memory. I
feel like this is more important than my packaging work in sparemint, in
fact it holds us from a number of major advancements. If I am stepping
on anyone's toes, please speak up, otherwise I'll assume nobody is
attacking this. I'll probably have questions ;)
I'm inspired to do this primarily because I should have been able to
read, understand and fix that malloc bug myself so I want to get
involved more. I have no idea if I can succeed at this. I need to
learn more 68k assembler I assume for much of the mmu work.
Do you want do implement process address space separation, or have one
big address space for everything?
AdamK
I don't even think it really qualifies as virtual memory if you use one
big address space.
I think process address space separation would be a key feature. One big
address space for everything would be easier to implement but I don't
really want to shortcut it.... unless you guys think a big address
space could work for our needs. For me the killer feature is being able
to instantly mmap something like 2GiB. That means implementing a page
fault hander, swap space, and other bits. I don't think you can really
use a single address space for that (unless we can do a 64 bit address
space? Again I am new to this). I'm still learning how the MMU works
and what it's responsible for (address translation, etc) vs kernel
code. I have all the right reference materials, it's just a matter of
learning it.
It looks like many features needed for virtual memory are implemented as
part of memory protection so this is likely an expansion of memory
protection. It looks like the very first thing would be expand the
page_type and build a page fault handler. As it is, I don't think we
were far from simple swap memory.