Roadmap 2020

[Roman Iten]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20200107/88c29ddc/attachment.sig>