Customizing the Goa run-stage

[Norman Feske]

Hello Pirmin,

 > Johannes Schlatow wrote:
 >> What about we'd be prefixing the specified label by a "tap_" e.g.
 >> instead?

Since the <requires> subnodes in the pkg/runtime are just XML, there is 
be no harm in adding custom attributes that can be picked up by Goa as 
hints. The name of the tap device could be a separate <nic> attribute 
that is ignored by Sculpt but interpreted by Goa. The use of explicit 
attribute values avoids the need for introducing conventions.

This reminds me of the similar problem about the distinction between 
different flavors of <gui> applications, some of which expect a window 
system (e.g., a multi-window application) where others might expect a 
raw nitpicker GUI server. Goa could look at a <gui wm="yes"> to decide 
whether to spawn a themed_wm or not. On Sculpt, those attribute would be 
ignored. These hints should remain as high-level as possible to grant 
Goa as much freedom as possible.

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

The direction bears the risk of making Goa more and more complex over 
time whereas I think that Goa should better remain largely agnostic wrg 
to specific components like the NIC router. Support for custom 
NIC-router configurations would effectively extend the user interface of 
Goa by the complete interface surface area of the NIC router. This would 
be a mistake because it sets the precedent to also expose the nitpicker 
configuration as a Goa feature next. Where do we draw the line?

In the concrete case, it would be most sensible to have dedicated 
(potentially multiple) Goa runtime projects that contain no code but 
only a pkg/runtime and a bunch of configurations in raw/ - as done in 
the Unix tutorial and also suggested by Johannes. Internally, such a 
pkg/runtime can have as many NIC routers with special rules as one 
wants. But from the outside, it would still be a subsystem requiring <N> 
NICs. Instead of adding features to Goa, let us better leverage the 
recursive nature of Genode.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth