Design Question about implementing RPC on top of IPC

[Sid Agrawal]

Hi Genode,
I am building userspace on seL4 directly and have run into a design issue.
I am implementing server and client using badged endpoints. I think Genode
would have run into the same issue, and I would like to understand better
how Genode solves it. It is not directly a Genode question, but I would
benefit from your experience. Below I have laid out the scenario, the
issue, and some questions.


*Scenario*

I have a userspace server that implements the functionality for an
object(say type obj_T1). The server hands out badged-endpoints to clients
to interact with this object. The badge is the virtual address of the
object's struct in the server’s virtual address space. A client can
interact with the object by sending messages on this badged endpoint. The
client never learns the badge value. The kernel extracts the badged value
when the server receives a message on this endpoint. By using the badge
value, the server knows which object the client is trying to manipulate.

The same PD, which implements the 1st server, also implements another
server(in a separate thread, but same address space) for another object
type (say type obj_T2). The server follows the same paradigm of handing out
badged endpoints and using the badges values to keep track of the object.


*Issue*
I have a scenario where the client wants to invoke the functionality of
obj_T1. This functionality needs access to obj_T2 as well. The client has
badged EP caps to both objects. The client can invoke the badged EP handed
out by server-1 for obj_T1 and give the badged EP of obj_T2 as an extraCap
in the IPC message(or vice versa). Since the server has no way to look up
the badge of the second cap, it cannot look up the underlying object for
obj_T2.

So my questions are:

   1.

   Is there a way for a PD to look up the badge value of badged EP? I think
   the answer is no, but I thought I would still ask.
   2.

   Is my idea of using the badge to keep track of the underlying object on
   the right track? Is there a better way of going about doing it?
   3.

   As a potential solution, I can extend my server to add a new function,
   say GETID, which returns the badge value of a given object(i.e., EP). Since
   I know that the server always badges the EP with the virtual address of the
   struct, it is a trivial call to implement. But I somehow feel like this is
   not a neat idea, not quite sure why.


Thanks for the help, everyone!

Thanks,
Sid
Graduate Student @ UBC
sid-agrawal.ca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20220419/3205cd86/attachment.htm>