I was thinking about memory management and I started wondering if I should be thinking of the memory managers as hardware drivers... It occured to me that they do control hardware and that on different systems with different memory controllers it can be necessary to write completely different memory managers. They are such a basic requirement that it never occurred to me to really think about this.
It also begs the second question of does it really matter at all what we classify them as? I doubt we would start treating them any different. Just a bit of a free-thought question for you though amid all the thinking that is required to solve problems on here ;D
Memory Manager Classification
-
Colonel Kernel
- Member
- Posts: 1437
- Joined: Tue Oct 17, 2006 6:06 pm
- Location: Vancouver, BC, Canada
- Contact:
Re:Memory Manager Classification
I've always thought of a microkernel as a CPU + memory + timer + PIC/APIC driver. It helps me decide what should go into user space and what shouldn't. Otherwise, I'm not sure that it matters.
Top three reasons why my OS project died:
- Too much overtime at work
- Got married
- My brain got stuck in an infinite loop while trying to design the memory manager
-
AR
Re:Memory Manager Classification
Depends on how you define a driver really. The memory manager doesn't really "drive" anything, it only manages (allocates/deallocates) memory, the HDD driver performs commands on the drive for instance, the only commands that happen in memory management is mapping pages in page tables but that would actually be part of the CPU "driver".
I believe the "conventional" term if you have the MM outside the kernel would be "Memory Management Server" (since it provides a service rather than driving something).
I believe the "conventional" term if you have the MM outside the kernel would be "Memory Management Server" (since it provides a service rather than driving something).
-
JoeKayzA
Re:Memory Manager Classification
I would say that the low level portion of the memory manager (that does the page table manipulation) could be seen as a driver, since you can also have different implementations (PAE, for ex.), depending on the amount of memory installed and what the CPU supports. Don't know whether other processor architectures also offer multiple different implementations of paging, this might be an x86-only issue.AR wrote: Depends on how you define a driver really. The memory manager doesn't really "drive" anything, it only manages (allocates/deallocates) memory, the HDD driver performs commands on the drive for instance, the only commands that happen in memory management is mapping pages in page tables but that would actually be part of the CPU "driver".
cheers Joe
-
Kemp
Re:Memory Manager Classification
Yeah, one of the reasons I came up with this is that I saw the variations for PAE/PSE/SMP compatibility (heh, all TLAs but the third one is quite different). You can have a generic x86 memory manger that'll work with any compatible system and specific ones to support specific variations, which started sounding scarily like all other drivers to me.
-
JoeKayzA
Re:Memory Manager Classification
In linux, you have the choice which mode (standard paging, PAE) of paging you compile into the kernel, but they are fixed parts, you can't (AFAIK) load them as modules. The windows NT kernel has both linked in statically, and you specify the used mode through a boot parameter.
The point is that paging is needed immediately after bootup, so you won't have much time to load and link a module, like you would do with other drivers. When you have a look at microkernels: They normally tend to run drivers in user space, but the paging code must still be linked into the kernel image, that runs in kernel space (and all ?-kernels I know do this). A serious point that differenciates the paging code from an IO-driver is, that it needs access to privileged instructions (invlpg, writing cr0, cr2 and cr3), while an IO-driver normally comes clear with certain memory and IO regions, receiving interrupts.
There are several points, you see, that lead to the conclusion that you should not handle paging code as a driver. I'm still not quite sure about this, for me, in my current OS project I'll do it the 'traditional' way, however.
cheers Joe
The point is that paging is needed immediately after bootup, so you won't have much time to load and link a module, like you would do with other drivers. When you have a look at microkernels: They normally tend to run drivers in user space, but the paging code must still be linked into the kernel image, that runs in kernel space (and all ?-kernels I know do this). A serious point that differenciates the paging code from an IO-driver is, that it needs access to privileged instructions (invlpg, writing cr0, cr2 and cr3), while an IO-driver normally comes clear with certain memory and IO regions, receiving interrupts.
There are several points, you see, that lead to the conclusion that you should not handle paging code as a driver. I'm still not quite sure about this, for me, in my current OS project I'll do it the 'traditional' way, however.
cheers Joe
-
KeeperOC
Re:Memory Manager Classification
I think the main difference between memory managers and drivers is the interface. A driver is a go-between - if I want data from my NIC/drive/et cetera, I communicate with the driver and it interacts with the device - whilst a memory manager is an overseer, ideally acting without the client applications even knowing that it exists. The similarity exists only in so far as resource management & synchronisation is concerned. If we were to consider a single-tasking system, that task could hypothetically never know that memory management was present (as it would be dealing solely with paging, and not malloc()s, et al), whereas it would definitely 'know' about the drivers that it accessed.
Keeper
Keeper