Customizing the Goa run-stage

[Pirmin Duss]

Hello Johannes

Thanks for your quick response.


On 6/23/23 13:44, Johannes Schlatow wrote:
> Currently, the label of the required nic service determines the name of 
> the tap device in Goa. I understand that, to make archives deployable, 
> one would not want to have a "tapX" label in the runtime. What about 
> we'd be prefixing the specified label by a "tap_" e.g. instead? This way 
> you could have a "eth0" label, which will get mapped to a "tap_eth0" 
> device by Goa.

This is a very neat idea, which maps what I had in mind very well. Shall 
I create an issue for this?


> This should be pretty straightforward to implement. Would you mind 
> opening an issue for this so we can continue the discussion on github?

I did create https://github.com/genodelabs/goa/issues/57.


> The major difference between Goa and hardware deployments is that the 
> latter usually have one or multiple managed Nic router(s) while Goa has 
> no way to customize the Nic router config (yet). The current workaround 
> has been to create an pkg archive in Goa that is deployable on hardware 
> and add another Goa project that wraps a Nic router with a custom config 
> around the other pkg. You can find an example of this in my goa-pkgs 
> repo [1] where I have a vnc_server and a test-vnc_server project.
> 
> I see that, an some point, we probably need to integrate a means to 
> provide Goa with a custom Nic router config. Maybe this could be done by 
> adding a 'nic_router.config' file into the project directory. If this 
> file is present, Goa would take its content as config for the Nic router 
> instead of the default config. However, what shall happen if there are 
> multiple Nic router instances?
I like that the user can provide a customized 'nit_router.config' if 
needed. For multiple NIC interfaces, one could use 
'nic_router_<label>.config'. I would use 'nic_router.config' only for 
the case when only one `<nic/>` is required.

I only fear that the project directory could get cluttered with 
additional files. What do you think abort creating a directory that 
contains the files to customize the run-stage? With this, one could also 
take the external ROMs from there.


Regards,
Pirmin