Roadmap 2019

[Norman Feske]

Hi Ben,

I very much appreciate your plans and suggestions. Thanks for chiming in!

On 24.12.18 20:22, Nobody III wrote:
> *Desktop Environment*
> 
> I also see having a desktop environment as priority, and I have already
> made some progress in that direction. I have my plans along those lines,
> and if anyone wants to discuss details, I'd be happy to do so in another
> thread on this mailing list. However, I have run into some hurdles that I
> could use some help with. In particular, to enable easy IPC with libc-based
> applications, a named pipe (FIFO) VFS plugin would be extremely useful. I
> wrote one myself, only to discover that the VFS and File_system interfaces
> do not adequately support partial writes, as needed by such a plugin. With
> those interfaces reworked, I would happily modify and provide my VFS FIFO
> plugin code, as well as my Libc pipe plugin that uses it as the backend.

These are no fundamental show stoppers and I'm very hopeful that we can
remove these limitations soon.

> My other main technical hurdle for creating a desktop environment has been
> converting the init component into a library to allow for easy
> customization beyond what is possible through configuration files alone.
> The current method of writing a monitor component to read init's state and
> modify its configuration works fine for simple cases, but it has
> performance penalties that can range from mild to severe. The configuration
> parsing overhead grows with the number of child components, which isn't
> ideal, but the real show-stopper that I see is dynamic quota management.
> Each quota upgrade has to wait for a new report, and reports happen at
> regular intervals, usually every second. Thus multiple quota upgrades, e.g.
> from opening one or more new web browser windows/tabs can take several
> seconds. With an init library, such upgrades could be handled very quickly.
> I can handle this particular issue myself as soon as it becomes a high
> enough priority.

This is extremely interesting for me because I reached a similar
conclusion while creating the user interface for the sculpt manager. In
fact, I almost started working on the "librarization" of init in summer.
I ultimately decided to defer this work to give it appropriate attention
instead of rushing it.

Thanks for encouraging me. I will definitely put the "librarization" of
init on the road map!

> *Hardware Support*
> 
> Aside from a desktop environment, hardware support is another likely
> show-stopper for new users. I've been working on this myself, and hope to
> be able to make Genode/Sculpt usable on my new desktop computer in 2019. I
> accept that support for my hardware is mostly my issue, but improvements in
> debugging tools and documentation would help a lot with this.

I wonder, would any of these improvements be roadmap-worthy?

> *Debugging*
> 
> As for debugging tools, I suggest building both remote (serial and/or
> (W)LAN) and on-screen GDB component debugging scenarios. This would help
> with many other goals, and might also help make Genode more attractive to
> developers.

This problem can probably be addressed in two stages. At the first
stage, we should do a better job with documenting our existing
time-tested debugging and development workflows that are used within
Genode Labs. At the second stage, it may be cool to find a way of
integrating our GDB monitor easily in Sculpt.

> *Package Management*
> 
> I'd like to second and add to what ttcoder said about package management.
> It would be very helpful to provide a way for Sculpt users to discover and
> add depots. This would increase usability, and would encourage developers
> outside Genode Labs to write and port more software for Genode.
> 
> Currently, depots don't provide package or launcher lists. Ideally, I would
> like to see Sculpt have an option to fetch the latest launchers from the
> repositories selected by the user, allowing them to easily discover
> components. This would also fix the issue I've seen with Sculpt launchers
> expecting package versions only available locally on the build machine.
> Currently, when I modify a component used by Sculpt and update its recipe
> version, Sculpt expects my new version to be available from depot.genode.org.
> If a launcher list is fetched from the Genode Labs depot (possibly with a
> correct default launcher list provided in the Sculpt image), this problem
> will be solved.

These are all very good points. I definitely plan to improve Sculpt in
this respect. It is not as simple as importing pre-defined launchers
along with (potentially untrusted) depot content though. The launchers
should always remain under conscious control by the user. Imagine a
malicious depot provider that tricks the user into adding its depot
along with a launcher that hands out the user's config fs to a package
provided by the malicious depot provider. This could take over the whole
system.

I think we can get a convenient experience with a graphical user
interface that allows the user to select a package from a given depot
provider and then interactively construct a launcher. I'll try this out
in the next version of Sculpt. Let's see how you'll like it. ;-)

> *Performance*
> 
> All current Genode scenarios (AFAIK), including Sculpt, run almost
> everything on a single hardware thread. An SMP balancing component would
> dramatically increase performance (and likely responsiveness) on modern
> multi-core CPUs. If nobody else gets around to it first, I'll probably
> write such a component, but if anyone else here more familiar with Genode's
> scheduling mechanisms is interested enough, they can probably write a much
> better implementation than I would.

That is certainly an interesting topic. For Sculpt, a good first step
would be making init's affinity-managing feature available to the deploy
configuration. This would give the user an easy way to explicitly assign
workload to CPUs. Even though I see the balancing as a subsequent step,
you may already start experimenting.

> *Summary*
> 
> In short, I'd like to see the following things on the 2019 roadmap:
> 1. Rework VFS and File_system interfaces to support partial writes, as
> needed by FIFOs
> 2. Interactive local and remote GDB debugging scenarios for real hardware
> 3. Depot and Launcher discovery for Sculpt
> 4. SMP balancing component
> 5. Improved documentation

That's a very good and realistic list. Thank you for breaking down your
requirements to these tangible goals.

> We don't all see eye-to-eye on how a desktop environment should operate, so
> I'm particularly interested in getting help with (1) so I can make more
> progress on writing my own, and with (3) so I can make it easily available
> so others can try it out and give me feedback.

I wholeheartedly agree and look forward to this phase of experimentation.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

https://www.genode-labs.com · https://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth