Customizing the Goa run-stage

[Duss Pirmin]

Hello Johannes,

Thank you for sharing your thoughts.

On 21.06.23 14:47, Johannes Schlatow wrote:

> 
> 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.

I see your point. As we see no reasonable alternative, we will keep and 
maintain our own patch for this.


>  From my perspective: I'd appreciate your contribution ;-)

I'm working on bringing the patch to staging. I created issue #55 for 
this. I'm almost finished with the updated patch.


>> 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?

In our case, we deploy the resulting pkg archive to real hardware, which 
provides a nic_router outside of the runtime. Depending on the platform 
the runtime is executed on, I prefer more general name mapping 
accordingly. Therefore I suggest on `eth0` to `ethX`, which is mapped to 
`tap0` to `tapX` for the Linux case.



>>   - 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.

I like the idea of starting a separate nic_router per <nic label=""/>! I 
would also start a nic_drv for each to make things easy and straightforward.


>>   - 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.

Our use case is that we want to utilize Goa to build Gateway 
applications that may require multiple network interfaces. We want to 
test the pkg runtime on Linux via tap devices and then build and deploy 
the pkg to the Gateway hardware. The device that the pkg archive is 
deployed to also runs other sub-systems that require networking. By 
integrating a nic_router in the pkg runtime that provides the Uplink 
sessions, the nic drivers would be limited to networking for that 
particular pkg runtime, right?


Regards,
Pirmin