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