Roadmap 2020

[Martin Stein]

Hey Norman,

Thanks for the annual poke!

For 2020 these are my interests:

* Provide a Genode kernel that is written entirely in Ada/SPARK, i.e.,
try to eliminate the use of base-hw code (C++) in the Spunky kernel that
I started last year. Spunky currently aims only for the basic kernel
features (e.g., no virtualization) and only for x86_64.

* Once, the Spunky design is independent from base-hw, try to find a way
to modify the design in a way that SPARK-compliance can be reached. If
successful, show absence of runtime errors via gnatprove.

* Try to find ways to let further core functionality of Genode benefit
from Ada/SPARK. Especially the Core component and the base library are
of interest for me. Building an Ada-only Core using Spunky would be a
cool goal.

* Also, the NIC router has reached a state that makes me believe that a
review of the internal design would be useful.

Cheers,
Martin

El 27/12/19 a las 14:33, Norman Feske escribió:
> Dear Genode community,
> 
> the year 2020 is approaching, which prompts me to kick off the
> discussion of our road map for the year to come. Before drafting plans,
> however, I'd like to share my personal reflections of the past 12 months.
> 
> For the road map 2019, we picked "bridging worlds" as our guiding theme:
> (1) Lowering the friction when combining existing software with Genode,
> (2) Fostering interoperability with widely used protocols and APIs, and
> (3) Making Genode easier to approach and generally more practical.
> 
> With respect to (1), we identified Genode's custom tooling (build
> system, run scripts, ports mechanism, depot tools) as a point of
> friction. They are arguably powerful and flexible but require a lot of
> up-front learning. This is certainly a burden unacceptable for a casual
> developer without a black belt in Make and Expect/Tcl. The new Goa tool
> rearranges the existing tools in a way that puts the concerns of casual
> developers into focus, allowing for the use of commodity build systems,
> eliminating Tcl syntax from the equation, running sub-second test
> cycles, and streamlining the packaging of software.
> 
> On account of (2), we switched to C++17 by default, fostered the use of
> Java, updated Qt5, and put POSIX compatibility into the spotlight. We
> were eventually able to dissolve the need for our custom Unix runtime
> (Noux) because all features of Noux are covered by our regular libc now.
> 
> Our biggest step towards (3) is the https://genodians.org website we
> started in winter 2019, which gives individual members of our community
> an easy way to present thoughts, projects, and experiences.
> Complementing Genode's formal documentation, it also conserves practical
> tips and tricks that were previously not covered in written form.
> 
> When speaking of "bridging worlds", I should not forget to mention the
> tremendous effort to bring Sculpt-OS-like workloads to the 64-bit ARM
> world. Thanks to the added support for multi-core AARCH64,
> hardware-based virtualization, and network/USB/graphics drivers for the
> i.MX8 SoC, the flexibility of Sculpt OS will eventually become available
> on PC hardware and ARM-based devices alike.
> 
> Over the course of 2019, we admittedly skipped a few topics originally
> mentioned on our road map. In particular, the user-visible side of
> Sculpt OS received less attention than originally envisioned. We also
> deferred several ideas we had in mind about reworking our GUI stack.
> Instead, we expanded our work in the areas of storage (block-level APIs,
> test infrastructure, block encryption) and input processing. This shift
> of focus is mostly attributed to the priorities of Genode Labs'
> customers who fund our work.
> 
> 
> Drafting plans for 2020
> -----------------------
> 
> Hereby, I'll just present my personal interests and invite you to do the
> same. When carving out Genode's official road map for 2020 until mid of
> January, I will then try to condense all the input into a tangible plan.
> 
> Personally, I think that after "bridging worlds", it's time for "use,
> consolidation, and optimization".
> 
> - It is certainly too early to call Goa a success. In order to find out
>   if we are on the right track, I want to expose Goa to as many problems
>   as possible, primarily by the means of porting software.
> 
> - I'd love to pick up our ideas about Genode's GUI stack, accommodating
>   headless scenarios, multi-head, screen capturing, color depth, and the
>   ability to restart drivers.
> 
> - I have a huge backlog of ideas about the user-visible side of Sculpt
>   OS, which would make Sculpt OS more pleasant to use and much more fun.
>   E.g.,
> 
>   - Replacing Unix/Vim-based interface of the Leitzentrale with a
>     graphical user interface
>   - Making the Leitzentrale's layout more logical
>   - Keyboard-based navigation
>   - Context-aware on-screen documentation
>   - Settings embedded in the graph nodes of the runtime view
> 
> - I see plenty of opportunities for optimization throughout the entire
>   software stack. With the rich C runtime in place now, it becomes
>   easier than ever to stress the system from various angles, which is
>   a great motivator for optimization work.
> 
> - Genode's binary compatibility across a variety of kernels is a key
>   feature of the framework. I'd like to push it even further by unifying
>   the capability-space management among all the kernel platforms.
>   Such a consolidation would make Genode less reliant on the subtle ways
>   how edge cases are handled by each kernel (in-kernel data structures,
>   capability re-identification), and reduce the amount of kernel-
>   specific code to maintain.
> 
> 
> This is merely my personal point of view. Now I'm very interested in
> learning about your's! Please don't hesitate to share your perspective
> on the project, your priorities and plans, and topics you would
> anticipate most.
> 
> Cheers
> Norman
>