Roadmap 2021

[Norman Feske]

Hi Colin,

thank you for having taken the time to present you perspective!

On 19.12.20 05:45, Colin Parker wrote:
>    As a hobbyist who's been following Genode for about a year now (I was
> running Sculpt on my home computer for a few months), I thought I would
> offer a few thoughts. Since I mostly do stuff for fun and at a slow
> pace, I don't expect to be influential in any serious way, but perhaps
> the perspective of hobby users is valuable nonetheless? Overall I'm very
> impressed with Genode/Sculpt - the philosophy and approach is pretty
> cool, and I have some successes with it. For example, I was able to port
> the Qt version of the "2048" game, and recently I have been trying to
> port the HelenOS driver for AR9271 usb wifi dongle - it is work in
> progress and non-functional currently. I also appreciate the level of
> active development going on - each new update brings cool stuff, so I
> think the past year of Genode updates was interesting to see.

It's great to know what's boiling in your kitchen. ;-) I'm happy that
your enjoy Genode.

> If there's one wish I have it would be better hardware support and
> resiliency. Currently, unless I misunderstand, the hardware support list
> mostly reflects the hardware that Genode Labs uses, and there doesn't
> see to be much dynamic handling of identifying and loading drivers.
> Example 1 - Sculpt will try to load a PS2 driver even on my Apple
> hardware that doesn't have any, leading to system crash. Example 2 -
> Sculpt uses pretty simple hard-coded logic to select which framebuffer
> driver to use, when I was expecting an XML file somewhere to allow more
> fine-grained control of which vendor/product IDs to assign to which
> driver (and also to identify and match other drivers, I guess).

Given the quite small amount of drivers, I found it too early to
introduce a formalism. In the longer term, once the driver landscape
becomes larger, we will certainly need to rethink this part.

As a general direction of Sculpt, I'm thinking of dissolving the static
partitioning of the system into the drivers / leitzentrale / runtime
subsystems. E.g., the dynamically started drivers should better be
hosted in the runtime subsystem (e.g., as done for the wifi driver
today). This way, those drivers and their resources become easier to
manage. The separation of these three subsystems - and the distinction
between the driver manager and the sculpt manager - was certainly useful
during the first evolutionary steps of Sculpt. But since Sculpt has
outgrown this phase, these early design decisions deserve a reconsideration.

> Example
> 3 - When the FB driver crashes, the rest of the system is resilient and
> continues to run. But, of course this is nearly useless because there is
> no way to reset the driver. Given my understanding of the
> component-based architecture, it seems like these things shouldn't be
> insurmountable issues. It should be possible to identify a failed
> component, kill it, and replace with a new instance, I think? It would
> be fun, in non-embedded applications, to be able to compile an
> experimental driver within a VM, push the result back to the running
> system, test it, tweak and recompile, etc. With that kind of workflow,
> maybe we could hope for more experimental/community drivers, at least on
> PC hardware?

I 100% share this vision and think that we are on a good way. The
foundations for restarting input and framebuffer drivers are in place
now, and network drivers are currently being worked on. We should
definitely let Sculpt reap the benefits of this work.

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