Hi Markus,
let me add my opinion on the topic. Even though it is possible to probe for the existence of sessions as currently done by L4Linux, I think that this approach is ill-fated and should not be taken as blue print. Putting such "intelligence" in a component is violating the principle of least surprise because the component will behave differently in two different scenarios even if the same config is used.
Having such built-in heuristics does mix mechanisms (the functionality of the component) and policy. On Genode, we generally aim to keep policy separated from mechanisms. The purpose of a component is to provide a mechanism only. The policy should solely be provided by the parent (and implicitly the grandparent etc.).
I think that the ultimate approach is to let the parent specify the desired behaviour in the config file supplied to the component instead of implementing any policy (such as probing) in the component. Fetching an argument from the config file is easy enough.
Cheers Norman
On 10/11/2012 03:28 PM, Stefan Kalkowski wrote:
Hi Markus,
in fact the desired behaviour you've described is actually implemented, and for instance used by Genode's L4Linux clone to discover device services. For instance, L4Linux probes for a NIC session to init, but if there is no route to NIC defined init will answer with an exception code. The ipc framework then throws the corresponding exception on the client side which is caught by L4Linux. When catching the exception Linux knows there is no device available and will return from it's device driver's probing code.
For an example, have a look at: ports-foc/src/lib/l4lx/genode_net.cc:86
The point that matters is of course, that init's configuration doesn't promise that such a service is available (no 'provides' or 'parent-provides' statement with the appropriate service name should be available) this would clearly be a configuration bug.
I don't know if this satisfies your question, otherwise would you please post an example (including the configuration)?
Regards Stefan
On 11.10.2012 13:00, Markus Partheymueller wrote:
Hi Folks,
I recently stumbled across an issue when connecting to a service that is non-essential for the child. Currently, the connection attempt, although surrounded by a try-catch block, leads to an abort call by init. While this seems logical for essential services, it is not intended for service connections that are optional. I'd rather that one could try to connect to the service and react to a failure of this attempt in a way the client has to define. If the client can live without the service, it should be allowed to carry on. In my opinion, this decision should be up to the client, not to the service framework of genode.
Is there any chance to find out if a service exists without getting aborted? Any hint would be appreciated.
Cheers
Markus