I was rereading Genode Foundations, and thinking about a project that will likely go nowhere involving record / replay & time travel debugging, and had a few questions about the design of shared memory
For shared memory, the server always creates the dataspace on behalf of the client. I assume this is because if the client made it, the client could cause the server to misbehave by deleting it?
It’s noted elsewhere under synchronous bulk transfers that the client could continue writing while the server is reading. I assume the lack of protection here is a performance optimization? As revoking the write capability would need a kernel operation & updating the virtual memory.
Is there any such think as a read only or write only capability for shared memory?
Mostly asking for curiosity’s sake, but client and server being able to communicate at any time over a shared memory interface makes tracking all inputs and outputs a lot harder. A lot of interfaces seem much more stable in practice (framebuffer server will not write pixels ever, clients will not write to memory while they’re waiting for the server to read etc.) but not guaranteed
Warning: very superficial (and possibly very wrong) appetizer response ahead, someone else would have to flesh it out to make it more yummy!
My understanding is that the core ‘primitives’ are basic building blocks, that can be used for building more elaborate, application-facing, building blocks and components.
So for instance if you use the RM service “raw”, then there is no inherent synchronization, the reader and writer can access the memory at the same time. But Genode does not require you to use it directly, just like on other OSes, they do not require you to use bottom-level kernel primitives: if you want sync’ed shared memory, use the “report_rom” component or some such, which builds upon the basic primitives and combines them together (an RM capability plus a signal capability, plus a mutex, plus…) to provide for real-world use.
As to 1., I don’t have that part of Foundations in mind, but as a quick guess, I suppose the DS is (ideally/typically) provided out of the client’s quota, but its ownership is transferred to the server, or parent init, so that, when/if asked to kill the child, then parent init can do it easily?
Re. 3., I’m guessing e.g. “code” segments are typically read-only and in fact that kind of protection is pervasive throughout the Genode code base (i.e. not just code segments but much more) but again I’m the wrong person to answer.