Sawmill's dataspaces and the Hurd's physmem
darwin.yuan at freescale.com
Tue Oct 18 13:42:27 CEST 2005
I think these 2 approachs are not incompatible. Here are the reasons,
1. In Hurd's approach, every application could manage its own physical memory. However, for most of application developers, they don't want to take care of the VM replacement policy. To solve this problem, Hurd has to provide a general VM server to be the pager of this kind of applications. However, as the philosophy of Hurd, should this applications trust this server?
2. In Sawmill's DS approach, every task(AS) has a specific thread named "region mapper" to be the pager of other threads. It captures the page fault, then decide to forward it to corresponding server, and get mapped. So from the higher level point of view, these servers are the pagers of the task. If Hurd application should trust that general VM pager, the applications using Sawmill's DS framework should trust these servers as well.
3. Relative to Sawmill's approach, Hurd provides a clear & great physical memory server, which makes the whole physical memory of platform could be fairly used by all of the servers & applications.
Therefore, we can use Hurd's physmem server as the central controller. Sawmill's DSMs apply physical memory from it. The applications who wanna use Sawmill's approach could still walk on their own way. For some applications who wanna manage their own physical memory, they can apply memory from physmem server directly.
[ physmem ]
[ DSM ] [Hurd app] (manage physmem by itself]
[Sawmill app] [Sawmill app]
More information about the l4-hackers