On 08/31/15 19:30, Tom Mitchell wrote:
On Mon, Aug 31, 2015 at 2:28 AM, Gernot Heiser <[email protected]
<mailto:[email protected]>> wrote:
On 31 Aug 2015, at 18:57 , Raymond Jennings <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
Devel mailing list
[email protected]
https://sel4.systems/lists/listinfo/devel
