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