Hi Sid, I'm not an expert regarding the topic you're in. However, if I'm not mistaking, the badges you're talking about sound like what is accomplished by the so-called ID space in Genode [1][3][4].
Some examples on how ID spaces are used are the Trustzone VMM block driver [2] that manages its device objects with IDs, the VFS file systems [5] and GPU buffers [6]. Maybe, looking into that code provides you with some answers. Let me know if so! Cheers, Martin [1] <GENODE>/repos/base/include/base/id_space.h [2] <GENODE>/repos/os/src/server/tz_vmm/include/block_driver.h [3] https://genode.org/documentation/genode-foundations-21-05.pdf 8.8.4. ID space [4] grep -r "ID space" <GENODE>/doc/ [5] <GENODE>/repos/os/src/lib/vfs/fs_file_system.h [6] <GENODE>/repos/os/src/drivers/gpu/intel/main.cc On 20.04.22 00:42, Sid Agrawal wrote: > 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 knowswhich 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 givethe badged EP of obj_T2 as an > extraCap in the IPC message(or vice versa). Since the server has noway > 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 <http://sid-agrawal.ca> > > _______________________________________________ > Genode users mailing list > [email protected] > https://lists.genode.org/listinfo/users > _______________________________________________ Genode users mailing list [email protected] https://lists.genode.org/listinfo/users
