some other memory considerations.

[Rian Hunter]

I have one concern that I think is valid to consider when designing (or 
re-designing) the memory system, especially after that long IPC 
security/method discussion.

How will copy-on-write from untrusted-task to untrusted-task work? For 
example, let's say a client mmap()s a file from some arbitrary 
translator. To do something like copy-on-write (instead of memcpy three 
times in some way using containers) the translator would have to request 
to physmem that it maps that certain page to the client task.

This would be a lot speedier than copy, copy, copy using a container, 
and follows the current convention of not allowing untrusted tasks to 
directly map to each other. So this should really should be considered 
when working out the details of the memory system.

Complications that arise with copy-on-write through physmem would be if 
the translator that actually owns the page is killed somehow, then the 
task server would be required to notify the physmem server to actually 
copy whatever pages are copy-on-write from that translator to the client 
tasks.

Another complication is how would a copy-on-write page be classified to 
a client task? Would it be considered owned by it and count toward it's 
total page count, or will physmem not count it, unless it actually gets 
copied. In the case that a copy-on-write page is suddenly copied into 
the client task, but the client task has already exceeded its allowed 
number of pages and the physmem server is doing an audit, what would 
happen? Would it count toward a guaranteed frame or extra?

By the way, is it even possible for two arbitrary tasks in L4 to map 
memory to each other, assuming not one of them are pagers to the other? 
I'm not entirely sure but I don't think so.

-rian