Roadmap 2023

[Alice]

Dear Genodians,

I start by mentioning that I am Jean-Adrien from Gapfruit. Sorry for the confusion
I may create. I mailed you on my behalf today, with my private email address, to avoid
interfering with any Gapfruit matter.

I take your email, Norman, as an opportunity to share my enthusiasm about Genode. I may not
have a significant contribution to make to the roadmap. But I would like to share some
of my interests and motivation. This year I want to spend more time on contributions
that can benefit the community.

First, I will fix issues I have with my test machine to run Sculpt fully featured. Currently,
networking via Wifi is not possible. Other difficulties may come after improving connectivity
support.

Next, I want to put effort into proposing 1) when I have finished with the 22.11 update
integration and other work-related priorities.

Then during my spare time, I would like to join efforts on support for Xen or Virt. Layer
for Qube, adjusting myself to ongoing plans, if any exist? 

Following the "Roadmap 2023" discussion and after having a recent look at "Futur Challenges" [1]
on the website, it is with lots of excitement that I found many subjects very close to my
interests. Here are the topics:

 1. Character device drivers as VFS plugins

I proposed, some time ago [2], an SPI driver. The commits never made it to the staging branch
because of the interfacing / "quality". Over time, at Gapfruit, we gained experience using the SPI bus,
but only with TPMs. We recently refactored it into a VFS plugin for easier interfacing with libraries
such as WolfTPM and TPM TSS. I believe BUS drivers such as I2C and SPI could be unified behind a standard
"character device" VFS plugin interface. Can that benefit the community? I can put some effort into
improving and contributing those commits.

 2. Genode as virtualization layer for Qubes OS

I am a daily user of Qube OS. Sculpt is an attractive alternative! Trying it out as a daily OS is part of my plans.
I have little knowledge of the Qube OS internals, only that they use Xen as a hypervisor. I was surprised to
find out about the hypervisor abstraction layer they created. It is a game changer for using Genode to
build a virtualization layer.

It brings so many questions to my mind.
First, does full support for a hypervisor such as Xen need to find its way to Genode? Or is base-nova already a viable candidate?
Are all necessary building blocks for AppVM message passing present within Genode?
Which approach would you privilege first for investigation?
If Xen, support for Genode in a Dom0 scenario first?
Or, as an AppVM first, focussing on Qube RPC mechanism support? (I am aware of Xen DomU support, but I do not have all details in mind)
Currently, those questions might be off-topic. Overall, it seems a significant challenge.

 3. Xen as "Kernel" for Genode

My ultimate goal here would be to have a pure minimal Genode-based OS in Dom0 for only managing guests' VM.

Last summer, by curiosity related to 2), I started investigating necessary changes to the build system for building Xen as a port
and generating a boot image using Xen with a Genode base-hw minimal scenario as Dom0. I was able to set up
the port, successfully building Xen and booting it, but with a minimal Linux as Dom0 instead of a chosen
Genode scenario "run/log," e.g.

I still need to reach my goal. The real work only begins now. My primary technical motivation was working on
low-level mechanisms to manage DomU(s) and enable RPC from one DomU to the other. I lost interest over time because I needed
to be more confident in its relevance and missed lots of knowledge.

At that time, I was unaware of the work of Julian Stecklina. I would be interested in looking into it! Is it
publicly available?

-----

Side note about the AMD Radeon drivers, my x86_64 test machine is an HP Elitebook 849 G2 equipped with an
AMD Radeon R7 M260X. If some workforce is needed, I would also be happy to test and provide feedback!

Another topic I was very interested in is initiatives like Spunky [3]. I am not making it a point as this is not
to take as seriously as the others. With the gain of popularity from languages like, e.g. Rust. Is there any
plan or similar initiative in that regard?
I would be up to start one as a pet project. I am interested in trying this out with the Zig programming
language [4]. My motivation for such a language comes from a Youtuber I appreciate [5]. He made an interesting
video on memory safety within different languages [6]. I do not have any strong opinion on "C++ vs any other lang" topics.
If you have other languages in mind, please let me know!

Finally, thank you all for your supportive, kind and professional attitude! Since I started working with the Genode
OS Framework, it has always been a pleasure to read from and interact with any of you. I am relatively junior to OS development.
Thanks to my co-workers and following daily discussions on this mailing list, I learned a lot!

[1] https://genode.org/about/challenges
[2] https://github.com/genodelabs/genode/pull/4187
[3] https://genodians.org/m-stein/2019-05-09-spunky-1
[4] https://github.com/ziglang/zig
[5] https://www.youtube.com/@contextfree
[6] https://www.youtube.com/watch?v=qeiRGbYCD-0

Cheers,
Jean-Adrien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - alice at domage.cloud - 0x173B2B9C.asc
Type: application/pgp-keys
Size: 649 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20230112/3d0f1aa2/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20230112/3d0f1aa2/attachment.sig>