Hello Dan,
welcome to the mailing list!
Why appeal to ambient authority to print to the console? Why not pass a capability to main, as pony does with env https://github.com/CausalityLtd/ponyc/blob/master/packages/builtin/env.pony, capsicum at cap_enter() http://lwn.net/Articles/482858/, etc?
At lower levels of the architecture, genode has this structure; e.g. 3.5 component creation:
The environment is constructed by successively requesting the component’s RM, RAM, CPU, and PD sessions from its parent.Why not continue this structure in the base API?
That is a good point. In fact, we are currently revisiting the API in this respect:
https://github.com/genodelabs/genode/issues/1832
With the new API in place, each component will be called with a reference to its environment. The global accessor 'Genode::env()' will eventually be removed.
That said, we will maintain the side effect of a default output facility (printf, PDBG) for practical reasons. For debugging (the main purpose of those functions), it would be unbearable to always need to pass a reference to a LOG interface around.
I suspect that your assumption of this output facility relying on "ambient authority" is slightly mistaken. There is _no_ single console in a Genode system to which each component magically would have the authority to write. The component startup code requests a LOG session for its default output from its parent. It is up to the parent to route this session request to a LOG server or not. The parent takes a deliberate decision. From the perspective of the component, the LOG session is just there. But the component does never know where the output goes. It has no (ambient) authority over anything the parent has not agreed on.
In contrast to the interfaces for dealing with the component's address-space layout, RAM session, or CPU session, I cannot see any benefit to be gained from hiding the default LOG session from arbitrary component code. What do you think would be the advantage of changing this part of the API?
Cheers Norman