generic MM API
generic MM API
Ok, this might be a stupid question, but if it is it is because I am still reading a lot about memory managers and this just might not be possible, but I was wondering if its possible to design your mm in such a way, that your OS does not depend on it. For example, you could have one that implements paging, one that does not, and perhaps different schemes in both worlds, but the way in which you design your mm has no effect on the rest of the system, that is to say you can pick one at compile time and it shouldnt make a difference. The only reason I would do this is for research purposes, to perhaps see how different ones behave within the same system. The reasons I think it might not be possible is that there could be some intrinsic fact about paging that makes it so that you either use it or you dont and I just dont understand it yet because I am still learning it. Any thoughts?
-
- Member
- Posts: 368
- Joined: Sun Sep 23, 2007 4:52 am
Re: generic MM API
Get it? Either they behave the same (and then why bother implementing two separate system), or they don't (in which case it makes a difference and everything breaks)....and it shouldnt make a difference. ... to perhaps see how different ones behave within the same system.
- AndrewAPrice
- Member
- Posts: 2299
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
Re: generic MM API
It's entirely possible, you can reduce the exported functions down to:
- Resize kernel memory
- Create task memory
- Resize task memory
- Delete task memory
Also encourage position-independent code for CPUs without MMUs or can't remap memory.
- Resize kernel memory
- Create task memory
- Resize task memory
- Delete task memory
Also encourage position-independent code for CPUs without MMUs or can't remap memory.
My OS is Perception.
Re: generic MM API
Hi,
If you're feeling particularly masochistic, have a look at the linux source, particularly the /arch directory. IIRC (I can't be bothered to re-download it and check - you'll have to do that ), there is a specific architecture for MMU-less systems.
This means that the main Linux kernel has the same interface to memory management whether you are on a system with a MMU or not.
Cheers,
Adam
If you're feeling particularly masochistic, have a look at the linux source, particularly the /arch directory. IIRC (I can't be bothered to re-download it and check - you'll have to do that ), there is a specific architecture for MMU-less systems.
This means that the main Linux kernel has the same interface to memory management whether you are on a system with a MMU or not.
Cheers,
Adam
Re: generic MM API
Ill check it out. Masochism is a part of why I got into programming
Re: generic MM API
Whether this works depends on the architecture of your OS. In theory, a cleanly designed kernel should not know to much about things like paging etc. On the other hand, a memory manager running in user space cannot do certain things that are needed for swapping page directories etc., so the kernel must have some low-level knowledge of things.yemista wrote:Any thoughts?
JAL
Re: generic MM API
You may be interested in http://www.cs.ucsb.edu/~chris/teaching/ ... gops07.pdf. It's a paper about Singularity and in Chapter 4.2 they describe various protection- and memory models they explored. Singularity seems very flexible in this regard.
Re: generic MM API
Minix 2 i know and 3 i think uses a non kernel MM and access requests via a message API.
In the case of Singularity the MM could really be a user process and if it needs to talk to the hardware it can do it via the HAL. I dont know why they didnt - it would make porting to 64 bit and different machines so much easier. Obviously it would need to be similar to the GC and part of the rusted base. ( I think for this reason they didnt do it)
Note such a configuration does introduce more complexity in the boot sequence and you may need a mini MM in the boot.
Regards,
Ben
In the case of Singularity the MM could really be a user process and if it needs to talk to the hardware it can do it via the HAL. I dont know why they didnt - it would make porting to 64 bit and different machines so much easier. Obviously it would need to be similar to the GC and part of the rusted base. ( I think for this reason they didnt do it)
Note such a configuration does introduce more complexity in the boot sequence and you may need a mini MM in the boot.
Regards,
Ben