Hello Saurav,
thank you for your interest in Genode and welcome to the list!
I'm Saurav Sachidanand, and I'm a CS sophomore studying in India. For more than year I've been programming in Rust and have published some personal projects in it (few involving the Rust-C FFI) and have contributed a few patches to Servo (github.com/saurvs). I've also played around a bit with kernel modules in NetBSD.
That's a very interesting background.
I'm interested in working on Rust bindings for the Genode API. I'm also completely new to Genode, and so I'll spend time reading the extensive documentation and the Genode Foundations book, and building and running Genode, and will do independent research on the project. I'd greatly appreciate any guidance and pointers regarding this project.
With Genode 16.05, we added basic support for Rust to Genode. In particular, we integrated Rust's tool chain with Genode's build system so that Genode components can incorporate Rust code quite easily. In January, this integration was further improved as part of the Genode-ABI line of work.
[1] http://genode.org/documentation/release-notes/16.05#New_support_for_the_Rust...
You can find a very simple example scenario at 'libports/run/rust.run'. The corresponding test program is located at 'libports/src/test/rust/'. In the program's 'target.mk' file, you can see that the integration of Rust code with a Genode component is as simple as adding the .rs source files to the 'SRC_RS' variable.
That said, we have not actively used Rust in Genode yet. The logical next step would be making (parts of) the Genode API available as Rust bindings so that meaningful components could be implemented in Rust. This topic has two stages:
Client components
Most Genode components are merely clients of other components (aka servers). The interaction with those servers is based on the session interfaces as explained in the book. Therefore, to allow a Rust-written component to interact with the Genode world, Rust bindings for client-side use of these interfaces are needed. I would probably start with bindings for the 'LOG', ROM', 'Report', and 'Terminal' session interfaces, which would already allow for a big variety on interesting scenarios. At a later point, higher-level session interfaces (like 'Nic', or 'File_system') may be considered.
There are two particularly interesting aspects:
1. Applying the execution model of Genode's component API - where components are modeled as state machines that solely respond to external events - to idiomatic Rust language bindings. E.g., How to best realize the Rust counter part of Genode's 'Signal_handler' class template?
2. The representation of 'Genode::Capability' in Rust. In C++ the lifetime of capabilities is managed by modelling a capability as a shared smart pointer. How would Rust code refer to Genode capabilities in the best way? One option would be to wrap Genode::Capability objects in Rust objects. Another option would be to introduce an associative data structure.
3. The Genode API has a very rigid memory management scheme. E.g., there are no anonymous heap allocations. All dynamic memory allocations must refer to a concrete allocator instance and are accounted for. Can this paradigm be sensibly transferred to Rust?
Server components
Once client components are able to interact with servers, it may be interesting to look at the potential of implementing Genode servers in Rust as well. Here, the server-side bindings for the session interfaces come into play.
Further ideas
As you may know, the Redox project is part of the same GSoC mentoring organization as Genode. So it might be interesting to explore the opportunity by bring both projects closer together. One approach would be to make Redox components (like drivers or file systems) usable as Genode components similar to how we reuse Linux drivers via 'dde_linux'. You may investigate creating 'dde_redox' with the potential of igniting collaboration between the projects. Note that I see this as an alternative direction to the one outlined above.
I'd also like to ask if a scripting language has been ported to Genode. If not, I'd like to suggest working on porting Lua since it is widely used as embeddable and extensible language, and has a manageably-sized codebase so that it can be one half of a two part GSoC project.
You can find an example for Lua on Genode at 'libports/run/moon.run'. Alternatively, you may have a look at the Python example at 'libports/run/python.run'. Admittedly, however, those examples are merely toys as we have not cultivated the use of script languges on top of Genode so far.
Cheers Norman