Customizing the Goa run-stage

[Johannes Schlatow]

Hi Pirmin,

thanks for your feedback and for sharing your ideas...

On 21/06/2023 11:19, Duss Pirmin wrote:
> Hello Genodians
> 
> The direction Goa is evolving is really cool! The new and upcoming 
> features address topics that are perfectly aligned with how we currently 
> use, or plan to use Goa.
> 
> In addition to what is already addressed in issue #44 [1], in order to 
> run or test some more complex projects we use:
> 
>   - a source for random (this can be achieved using jitter_sponge)
>   - accessing externally provided ROM modules
>   - multiple Nic/uplink interfaces and a nic_router
> 
> 
> For the random source I have a working commit, that I will have to 
> update to cleanly apply on top of staging. This will start jitter_sponge 
> if <requires> <terminal label="random"/> is found. To make this 
> available in general, the jitter_sponge binary would have to be 
> published by genodelabs. Do you think this approach is reasonable?

In principle, such extensions are reasonable. In the case of 
jitter_sponge, however, this would mean that we needed to make the Goa 
release dependent on the genode-world repo. I would rather avoid this.

> For accessing externally provided ROM modules I already have a patch 
> that enables this feature. It uses a fs_rom and a lx_fs to access ROM 
> modules listed in  <requires> <rom label=""/>. If you think this could 
> be a commonly useful feature, I can contribute it.

I could imagine this to become useful for running multiple Goa 
instances. I particularly have the 'clipboard' ROM (and Report) in mind. 
Even though running multiple Goa instances is not an established use 
case (yet), routing unrecognized ROM modules to lx_fs instead of to the 
black-hole component would not be much of a difference for the naive 
user. In return, we gain the ability to change ROM content at runtime 
for development/testing. Combined with a similar setup for the Report 
service, this would basically provide a report_rom functionality that we 
can easily introspect.

 From my perspective: I'd appreciate your contribution ;-)
> Providing multiple Nic/Uplink interfaces and a nic_router will require 
> some more engineering to do right. Our workaround instantiates a fixed 
> configuration which matches what we need. This is obviously not usable 
> in general. I see the following points that need to be considered:
> 
>   - number and names of interfaces? Probably each listed in <requires> 
> by label.

Currently (i.e. with #44), Goa uses the label as the name of the tap 
device. Do we agree that, if multiple <nic/> requirements exists, Goa 
should instantiate several nic_drv components and provide separated 
networks?

>   - when to start nic_router? Probably not as easy as start it when 
> multiple interfaces are configured.

For a <nic/> requirement, the nic_router is always instantiated because 
only the latter provides this service whereas the nic_drv acts as an 
Uplink client. When multiple nic drivers will be instantiated (i.e. 
separate networks are required), we could also have multiple instances 
of the nic_router.

>   - how should the nic_router config be provided? Here I don not see yet 
> a satisfying and practical solution.

For customising the nic_router config, I would go for integrating the 
nic_router into the pkg's runtime and, instead of using <nic/> 
requirements, let the pkg provide a couple of <uplink/> services. This 
would instruct Goa to instantiate multiple nic drivers (currently 
restricted to one driver) as Uplink clients.

Cheers
Johannes