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