Hi all,
My name is Zach. I am a student at Kansas State University doing research with Dr. Eugene Vasserman (Cc). I have been lurking in the mailing list for some time now and I thought I'd introduce myself and ask a couple of "beginner questions" that I have after reading the Foundations book and playing with Sculpt.
[1] Is Seoul still viable for virtualization on Genode? If so, where can I find the documentation for writing a VM configuration? I am partial to Seoul over VirtualBox due to its smaller codebase. I checked the genode-world repository and the original (outdated) source repository, but was unable to find anything.
[2] What is the state of rust support for Genode? I have seen a few mentions of it in release notes. Can I make base API calls from rust (e.g., requesting sessions, creating child components, etc.), or is it similar to running applications with the POSIX compatibility layer?
[3] Which system calls are provided by the Linux driver environment? Is it viable for running arbitrary Linux applications/services (e.g., a container runtime)?
[4] What is the best way to determine the dependencies of a component? How does the Sculpt visual composition system determine which sessions are required? When trying to run a complex component (e.g., a VMM) I often find myself doing a lot of trial and error with including libraries and starting necessary dependencies in the run script. Is there a better, or more consistent, way to determine dependencies?
Apologies if any of these questions have obvious answers. If this is the case, I would appreciate a pointer to relevant documentation so I can investigate further.
Thanks in advance, Zach
Hello Zach,
Welcome to the mailing list ;)
I can answer only one of your questions partially. But I hope this still helps, and that others chime in to fill the gaps :)
On 14.09.23 22:59, Zachary Zollers wrote:
[4] What is the best way to determine the dependencies of a component? How does the Sculpt visual composition system determine which sessions are required? When trying to run a complex component (e.g., a VMM) I often find myself doing a lot of trial and error with including libraries and starting necessary dependencies in the run script. Is there a better, or more consistent, way to determine dependencies?
Sculpt determines the required services of a subsystem by looking at the <requires> tag in its runtime config. For instance, have a look at [1] - it defines a lot of required services as well as restricting labels for some. The same sub-system but with the ability to capture frame-buffer data in the VM can be found in [2]. Consequently, it lists the same services as [1] in <requires> but adds the Capture service. The first listed service is the one who's route will be printed as connecting line to your subsystem in the tree view. Some basic services (LOG, binary/lib ROMs, PD, CPU) must not be listed in <requires> as they are routed automatically. The list contains only those services that are routed by the user in the deployment menu.
Furthermore, the required binary/lib files must be listed in the <content> tag in the runtime file.
As far as I know, creating these two lists is still manual work of the integrator. Now, I don't know if this is what you described but I'll append my own procedure anyway:
When I try to create a package and its runtime file, I usually start by creating a run script that runs my sub-system without package management and, important, without default service-routes. Actually, at the beginning, the script contains no service routes at all, so, that the components have to tell me what they need. This way, I can iterate over the requirements much faster than with a package-based system. Additionally, I add routes only with the specific labels in this process, so, I get to find also the name of each ROM file that should be listed in <content>.
I would also appreciate a more comfortable solution for this. But, admittedly, my frustration was not big enough until now in order to prioritize it over my other work.
Does that answer your question?
Cheers, Martin7
[1] repos/ports/recipes/pkg/vbox6/runtime [2] repos/ports/recipes/pkg/vbox6-capture/runtime *ü a>
Hi Zach,
I'll answer the question which is in my core expertise and leave it to my colleagues to give possibly more nuanced answers to your other questions:
[2] What is the state of rust support for Genode? I have seen a few mentions of it in release notes. Can I make base API calls from rust (e.g., requesting sessions, creating child components, etc.), or is it similar to running applications with the POSIX compatibility layer?
Currently our Rust support is focused on leveraging the existing ecosystem, i.e. we focused on getting the unmodified Rust standard library to run on our FreeBSD-based compatibility layer (see the beginning of my blog post[1] for our rationale behind that).
Now, just as Rust links to our port of the FreeBSD C library via the libc crate, it would be possible to leverage Rust's Foreign Function Interface (FFI) to call into to our base library, which as you probably know serves as the abstraction layer to the various kernels supported by the Genode OS Framework. I would be very much interested to pursue this, but so far due to lack of commercial funding there is no timeline for supporting base API calls from Rust. I haven't worked with Rust's FFI in quite some time, so I can't estimate how easily this could be accomplished with rust-bindgen[2] or the cxx.rs library[3]. If you want to give it a shot, we can surely support you with getting the application to work with goa[4]. I will bring up base API support for Rust when we discuss next year's roadmap.
I hope that answers at least one of your questions!
Best wishes,
Ben
[1] https://genodians.org/atopia/2023-05-30-bringing-rust-back-to-genode [2] https://rust-lang.github.io/rust-bindgen/cpp.html [3] https://cxx.rs [4] https://github.com/genodelabs/goa/
Hello Ben,
On 15.09.23 10:46, Benjamin Lamowski wrote:
Hi Zach,
I'll answer the question which is in my core expertise and leave it to my colleagues to give possibly more nuanced answers to your other questions:
[2] What is the state of rust support for Genode? I have seen a few mentions of it in release notes. Can I make base API calls from rust (e.g., requesting sessions, creating child components, etc.), or is it similar to running applications with the POSIX compatibility layer?
Currently our Rust support is focused on leveraging the existing ecosystem, i.e. we focused on getting the unmodified Rust standard library to run on our FreeBSD-based compatibility layer (see the beginning of my blog post[1] for our rationale behind that).
Now, just as Rust links to our port of the FreeBSD C library via the libc crate, it would be possible to leverage Rust's Foreign Function Interface (FFI) to call into to our base library, which as you probably know serves as the abstraction layer to the various kernels supported by the Genode OS Framework. I would be very much interested to pursue this, but so far due to lack of commercial funding there is no timeline for supporting base API calls from Rust. I haven't worked with Rust's FFI in quite some time, so I can't estimate how easily this could be accomplished with rust-bindgen[2] or the cxx.rs library[3]. If you want to give it a shot, we can surely support you with getting the application to work with goa[4]. I will bring up base API support for Rust when we discuss next year's roadmap.
Since you mention this, I have been thinking about trying working on this since I have previously written software to generate Rust bindings for C++. Assuming that generating bindings is possible/easy, what would still need to be done to compile/link these into native Genode components (maybe at first with libc, and later without it)?
I hope that answers at least one of your questions!
Best wishes,
Ben
[1] https://genodians.org/atopia/2023-05-30-bringing-rust-back-to-genode [2] https://rust-lang.github.io/rust-bindgen/cpp.html [3] https://cxx.rs [4] https://github.com/genodelabs/goa/
Best, Timo
Hi Timo,
First of all sorry for my very belated reply! With the Sculpt release out of the door, I can share a few points that came up in discussions around Rust support.
Since you mention this, I have been thinking about trying working on
this since I have previously written software to generate Rust bindings for C++. Assuming that generating bindings is possible/easy, what would still need to be done to compile/link these into native Genode components (maybe at first with libc, and later without it)?
From my discussions at Genode Labs I have gathered that at previous attempts, automatically generating C++ bindings for the Genode API from other languages has not been very straightforward. Differences between C and C++ have been handled by providing a limited(!) C API tailored to specific use cases in dde_linux.
As I have previously written I have only worked with Rust's C FFI, but from my understanding of cxx.rs you could feed a Genode base library C++ header you are interested in into cxx.rs and make it generate the necessary ("Hidden C ABI") glue code. Now in case this is not already obvious to you, it should be possible to use our recent work on Goa support for Rust[1], and Goa should add the necessary linker flags to link to the base library, so that the generated C++ API interfacing code can link to it, and it should in theory just work.
If your question was aiming more at side effects beyond ABI translation: I'm not aware of anything else that would be needed to be done for the general use case. In other words, if you manage to make equivalent calls from the generated glue code, I shouldn't matter if the base ABI is called from Rust via a backend implementation from the libc, or if it is called directly from the C++ FFI translation code. There might be pitfalls that are not exposed when using the Genode base API from the Posix API, or when mixing the two (see e.g. [2]) that I'm not aware of.
All this being said, right now we don't have concrete plans to work on a Rust API for Genode. We feel that generating Rust bindings from our C++ ABI is a) potentially cumbersome and b) even if successful would result in an API that is not idiomatic and does not live up to our aspirations. Hand-crafting an ABI on the other hand would best be done in tandem with specific Rust components. There is currently no plan for a Rust component inside Genode Labs but we would be interested to explore a Rust API with a specific use case.
Best wishes,
Ben
[1] https://genodians.org/atopia/2023-10-26-a-first-complex-rust-package [2] https://github.com/genodelabs/genode/commit/d0a18461532cd7a5c1dadcc798bbea7d...
Hello,
On 14.09.23 22:59, Zachary Zollers wrote:
[1] Is Seoul still viable for virtualization on Genode? If so, where can I find the documentation for writing a VM configuration? I am partial to Seoul over VirtualBox due to its smaller codebase. I checked the genode-world repository and the original (outdated) source repository, but was unable to find anything.
it depends on how you define "viable" and whom you ask ;). I use Seoul on a daily basis, see [0] for ready-to-use packets, to operate a up-to-date Firefox and Thunderbird VM on Sculpt 23.04 on Intel notebooks and AMD desktop machines, so for me personally it is very viable. Thanks to the various virtio models support [1] it is comfortable nowadays to use it interactively. If you define "viable" as "same features and functionality" like the VBox VMM, then it is not at the same level. Some convenience guest integration features are missing, like shared folder or clipboard support, but nothing you can solve differently via a network connection. The 64bit VM support is on the way and looks promising. You can already test drive a 64bit Firefox VM version available in my alex-ab Sculpt 23.04 index. Compared to VBox, however, crafting a runnable VM is not ever straight forward. I personally succeeded in setting up and running Tinycore based VMs and installing and running a Debian VM from scratch.
If you look into the seoul.port [2] file in genode-world, you will find the links to the current used Seoul sources. [3] contains the package description I used to publish the ready-to-use Firefox & Thunderbird VM. [4] contains the used Seoul VMM configurations. There is no much high-level documentation about how to configure the Seoul VMM. In principle the xml tags used in [3], corresponds to the models in the sourcecode [6]. Each model contains a short description in the sources about the model and the possible parameters. If one wants to develop and/or play around with the Seoul VMM, the run scripts in [5] are handy. In principle they ease the generation of the Seoul VMM config and the final result look like in [4].
Cheers,
Alex.
[0] https://genodians.org/alex-ab/2023-05-09-seoul-23-04 [1] https://genode.org/documentation/release-notes/22.11#Seoul_VMM [2] https://github.com/genodelabs/genode-world/blob/master/ports/seoul.port [3] https://github.com/alex-ab/genode-world/commits/seoul_23_04_pkg [4] https://github.com/alex-ab/genode-world/commit/fb0d60b9c4aa538308f48d92b0f08... [5] https://github.com/alex-ab/genode-world/tree/master/run/seoul* [6] https://github.com/alex-ab/seoul/tree/master/model/*
-
Alexander Boettcher -
Benjamin Lamowski -
Martin Stein -
Timo Nicolai -
Zachary Zollers