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
_______________________________________________
Genode users mailing list
[email protected]
https://lists.genode.org/listinfo/users
