On 08/31/15 19:30, Tom Mitchell wrote:
On Mon, Aug 31, 2015 at 2:28 AM, Gernot Heiser <gernot@nicta.com.au> wrote:
On 31 Aug 2015, at 18:57 , Raymond Jennings <shentino@gmail.com> wrote:

Is there an easy way for one task to share address space with another task directly or does it have to go through the kernel/os and be emulated?
there’s nothing stopping you mapping the same frame into two different address spaces (provided you have the rights to do so).

I noticed that support for mapping memory is mostly low level assignment of physical frames to virtual frames via page tables, unlike Mach which uses memory objects.

IPC using shared memory policy needs to be considered and established.

Shared read-write both processes need to have the (exact?) same levels.

Shared rw --> ro is one way and the sender needs to be trusted
to do the correct things with data it has access to.
There is more to be considered... in a machine eyes-only needs
a policy where a decision can be made but no other output
is permitted policy.

Without a policy and strategy things get unsecured in a hurry.
One might simply use files and allow page cache to accelerate 
communication.   

Device drivers... ?
I suppose if you wanted to use shared memory for IPC you could always make a call to the designated "virtual memory" server to create a mappable object whose capability you could then pass to the target server to allow it to ask to be mapped.

Given the recent commentary that the OS needs to implement virtual memory itself you could say that it should also handle shared memory for IPC between "userspace" processes that depend on the server as well as the microkernel.

--
  T o m    M i t c h e l l