[GSoC] Rust bindings for the Genode API

[Norman Feske]

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_programming_language

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

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth