Physmem exists; Tasks self-paging

[Neal H. Walfield]

Good Morning,

For those of you following address@hidden, you will have noticed
[1] that last night I checked in a real physmem server and added
libhurd-mm.  For those of you who don't follow address@hidden,
last night, I checked in a real physmem server and added libhurd-mm.

physmem is the physical memory manager.  It doesn't do any virtual
memory management at all: it schedules physical memory allocations;
scheduling of the content (i.e. multiplexing of the frame) is the
exclusive domain of the applications.  In its current state, physmem
is able to allocated physical memory into and deallocate it out of
containers.  Clients (i.e. applications) can also map physical memory
into their address spaces.  The current code supports sharing of
physical memory between containers (a necessary prerequisite for COW
and copying physical memory between containers), however, actual
copying between containers has not yet been implemented.

libhurd-mm is the default per-task physical and virtual memory
manager: it multiplexes the physical memory available to the tasks,
manages the virtual address space mappings, handles page faults and
pages data in and out.  Currently, it supports allocating and
deallocating virtual memory mappings backed by anonymous storage.  The
task's pager thread is also brought up and it is able to handle page
faults.

In terms of POSIX, this means that mmap (for anonymous memory) and
munmap work which is a prerequisite for pretty much everything.

Details about the implementation can befound here [2,3].  For details
about the design, please look at Chapter 5 of the design document.


From here, the next step is to implement copying physical memory
between containers.  With this mechanism available, work can seriously
start on the device driver framework (deva and fabrica).  This is also
a prerequisite to the porting of libpager, the Hurd's library for
application level pagers, which is needed to flesh out the
implementation of the root filesystem (initially using a ramdisk until
the IDE driver is ready) and portability issues with the filesystem,
file and io RPC interfaces.

Thanks,
Neal


[1] http://lists.gnu.org/archive/html/commit-hurd/2005-01/msg00014.html
[2] 
http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/hurd/hurd-l4/physmem/README?rev=1.2
[3] 
http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/hurd/hurd-l4/libhurd-mm/README?rev=1.1