Hi Jimmy,
You are right to point out that my intent to refactor servers into
independent processes is at odds with them directly accessing each other's
data. I have not thought this through yet.
Additionally, I think I finally understood how unwrapping works - and this
yields quite nicely into why you might have been encouraging me to use the
same endpoint for all the servers(i.e., merge the servers). If I merge them
into a single server, I can hand out badged EP of the same original
endpoint to all the server's clients. Now unwrapping will reveal the badge
of any badged EP cap since they are badged versions of the EP via which the
message arrives. If I still want to encode type information(memory
allocator or vspace manager), I can encode that into the badge instead of
using a different un-badged endpoint for each type.
-Sid
On Thu, Apr 28, 2022 at 11:26 AM Jimmy Brush via Devel
In my setup, the root task implements multiple servers(memory allocator, vspace manager, CPU allocator). Each server is run in a separate thread. So, all the servers share the address space.
Each server thread(which implements only one server) waits on only 1 endpoint. Multiple clients have been handed a separate badged copies of this endpoint during some previous handshake.
I wanted to keep 1 EP per service for 2 reasons:
* Future-proofing: At some point, I might move servers to separate processes. * To restrict clients. For instance, if I want a client to talk to only the CPU server but not others, it has only the CPU server EP. I realize that this can still be multiplexed with this EP on the server side and the server type can be encoded in the badge too. So this in itself is not a great reason.
Why did you decide for all these servers to share the same address space?
If your intent is for the servers to be independent and factorable into separate processes, but you have two servers that need to know about the internal state of each other, should they be merged into a single server?
- JB _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems