Roadmap 2020

[Stefan Kalkowski]

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 at lists.genode.org
> https://lists.genode.org/listinfo/users


-- 
Stefan Kalkowski
Genode labs

https://github.com.skalk | https://genode.org