Hi Norman,

On Di, 2014-09-23 at 17:01 +0200, Norman Feske wrote:

Hi David,

...

in my setup, i have a parent process with multiple children with IDs, lets say the are named child_1 to child_3.

the parent recievces messages with an ID and should forward it to the child with the corresponding ID. Therefore all children announce the same service, lets say "child_communcation", to the parent.

In order to avoid ambiguities, the parent process would have to reconfigure its route every time a message arrives. that means if message with ID 3 arrives, the route for the service "child_communication" must lead to child_3.

this solution seems odd to me, am i missing a mechanism in genode that allows a parent to communicate with its children directly, when they all announced the same service?

admittedly, I struggle a bit with following your email. To clarify, with "parent process" you refer to a program that you created, or are you referring to an instance of init?

The former is the case. It is a programm I created and is started by init.

If the former is the case (what I'm expecting), how do you run the child processes? Are you using the Genode::Child class (from 'base/child.h') or the Genode::Slave class (from 'os/slave.h')?

I am using the Genode::Child class.

...

From where does the parent receives messages? From any of its children

or some other process?

The parent does not receive messages via genode's mechanism. In fact, my project is based on the TZ VMM. The messages reside in the RAM of the normal world (running linux). The parent process runs in genode in the secure world, reading messages out of a queue in the normal world's RAM.

Just to allow me to get a better grasp on your problem, could you outline the scenario in slightly more general terms?

All in all, i want to define a single service, which the children announce to its parent. The problem is how to let the parent send messages via the service interface to a designated child.

Cheers Norman

I hope I could clarify my problem, thanks for your reply! David

Hi Norman,

thanks for the detailed answer. I considered your hint regarding the trustworthiness of the clients: now the parent is providing the service to its children.works like a charm! the slave approach also worked, but i think the reversed way is more elegant. i should have thought of that earlier ;)

in the next step, the parent shall process the calls from its client. thus, its necessary that the parent knows the label of the child which issued the call. The child sets its label in Child_policy::filter_session_args(...). my question is: how does the parent obtain these session arguments ?

maybe there is another ( better? ) way to obtain the childs name?

thanks for your support! David

On Mi, 2014-09-24 at 14:31 +0200, Norman Feske wrote:

Hi David,

thank you for giving a bit more background about your work.

According to your description, the parent process spawns several services as its children and wants to invoke any of those services in any order. To accommodate this pattern (a parent uses a child as a service), we introduced the so-called 'Slave' utility. To illustrate how to realize a scenario like your's using this API, I have put together the following example:

https://github.com/nfeske/genode/commits/slave_example

The example consists of two parts. The 'test-slave_master' is the parent process, the 'test-slave_child' is the child that provides a "LOG" service. In the example, the parent starts two instances of the child service and subsequently invokes each of them. Hopefully, the example guides you to the right direction. If you have questions about the code, please don't hesitate to ask.

That said, let me point out a potential risk of this design. By having the parent use its own children as services, the parent has to inherently trust those children to respond to the RPC calls. In the example, the parent calls the 'write' function at the child. If the write function had bug (e.g., it keeps stuck in an infinite loop), the parent would wait infinitely for the response of the function. Consequently, the parent must trust the child in this respect.

If this is a problem for your scenario, I recommend to turn the client-server relationship upside-down: Implement a service in the parent where each child can pick up messages. So the each child calls the parent but not vice versa.

Cheers Norman