Hi all,
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?
regards David
Nice title...
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?
regards David
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.cl... _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
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?
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')?
From where does the parent receives messages? From any of its children
or some other process?
Just to allow me to get a better grasp on your problem, could you outline the scenario in slightly more general terms?
Cheers Norman
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 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
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
Hi David,
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 ;)
great that you found this consideration worthwhile. :-)
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 ?
The child creates the connection to your service by invoking the 'Parent::session' RPC call. The parent-side 'Child' object handles this request by calling 'Child_policy::resolve_session_request' with the session arguments as parameter. The label is just a part of the session arguments. By overriding this virtual function, you can monitor the arguments including the label.
Btw, the 'Child_policy::filter_session_args' function is not called by the child process but by the 'Child' object in the parent process. The terminology is a bit confusing: The 'Child' class represents the child inside the parent process.
However, addressing your actual problem, I recommend to not distinguish the children based on the labels supplied by themselves. A misbehaving child could forge the label and thereby trick the parent to do wrong things. The natural way to tell the origins of different requests apart is to hand out different sessions to each child. So when a child asks for session, hand out the child-specific session. E.g., you could host the respective 'Session_component' object as member of your child/policy class. So later, when a request comes in, it is dispatched in the context of the right session (that is associated with one particular child).
maybe there is another ( better? ) way to obtain the childs name?
Actually, child processes don't know their own names. Sticking a name to a child (or not) is entirely up to the parent. In the case of the init process, the assigned name is used to prefix the "label" session argument of each session originating from the child with the child's name. But that is just an option. You don't have to do that.
Cheers Norman
-
David Goltzsche -
Norman Feske -
Sartakov A. Vasily