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