Hello Roman,

thank you for sharing your view and needs with us. I want to respond to some of the addressed points in the following.

On Tue, Jan 07, 2020 at 04:40:57PM +0100, Roman Iten wrote:

Hello Genodians,

2019 has again been a great year to work with, at and around this fabulous project and unique community. As always, we at gapfruit are impressed with the improvements: some expected and some unexpected but not less delightful.

I'd also like to share some ideas from our point of view. It may sound (and probably is) more like a wishlist than an agenda. But let me assure you that we'll contribute whenever possible and reasonable.

Software Enablement

For us, this is probably the most volatile topic and priorities may change on a monthly basis. However improvements regarding feature completeness, performance, stability and production-readiness in the following areas is IMHO anyways well spent effort:

• libc: a lot has already been achieved in 2019 and with the number of

use cases growing, we expect even more improvements in 2020.

• networking: network support is available but as the number of

networking use-cases increases, we also need to spend more effort in networking. I.e. IPv6 will be required eventually as well. Also adding a reference board with several NICs to test and benchmark networking scenarios is desirable.

There is an ARM-based board target called 'nit6_solox', which contains two NIC connectors that are both useable under Genode. Moreover, you are of course free to have more than one NIC card in x86-based PCs.

• filesystem: a native, production-ready filesystem will be required

sooner or later. lwext4 is already supported by the Genode framework. Production-readiness in real life scenarios has yet to be proven. I guess networking and filesystem support is very much in line with Christians Genode-based router and NAS vault.

• Java: it's great to have Java support! Yet some work has to be done to

make this support more generic. Namely some mechanism that allows to customize the "classes.tar" (which is currently managed in the port "jdk_generated" of genode-world) depending on the scenario.

• LLVM: Emery's proposal regarding the LLVM based toolchain is great. It

will open up many new use cases and migration paths.

Hardware Enablement

Genode Labs maintains some representative HW targets for different architectures which is good. However in our experience it's unlikely that a user will use exactly one of these targets. The only way I know to support a different target (like a new ARM board) is to add patches on top to the Genode repository. These patches will never be pushed upstream, which means that users actually have to maintain forks of the Genode repository. IMHO in the short, mid, or long-term it is desirable to add hardware support in dedicated repositories, similar like it is done for 3rd-party software with the genode-world repo. Imagine for example a "genode-nxp-arm" or "genode-marvell-arm" repo providing the hardware enablement for SOCs and boards. However, this can't easily be achieved and may require some kind of a common interface to "plug-in" such resources.

I definetly agree with this need. But I think that genode-world is for the time-being the right target for SoC/board-specific parts not maintained by Genode Labs directly. There are already examples for Zynq-centered boards running with base-hw in it. I also like to abondon several ARM boards not tested regularily in our test-farm to genode-world. Please, refer to issue 3168 in our issue tracker for details:

https://github.com/genodelabs/genode/issues/3168

Best regards Stefan

Tooling / SDK

It's great how well the depot and run tools can be used in the stages "extract", "build", "run" and "deploy" of our continuous integration pipeline! Since such a CI/CD infrastructure is most useful when it provides near instantaneous feedback on quality issues or regressions, optimization is key. Along the way of optimizations, we expect some effort on the following topics:

• Extract SDK from Genode repository that can be used in 3rd-party

repositories: I think Emery has once done something in this direction. Together with the SDK, the information about current depot archive versions need to be passed along. This would allow to create system integration projects which *depend on* a specific version of the Genode framework, *instead of adding them* to the Genode framework.

• Add support to create, sign and share contrib archives (ports): Maybe

the depot tools can be used as well for "preparation"/integration of 3rd-party code. If this is true, the port tools can probably be deprecated. Or more likely, they may become the plumbing with the depot-tooling as the new porcelain?

I didn't have the time to dive into the new Goa tool yet. Please bear with me if it already covers the above points ;)

Cheers, Roman

---

Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users