[Karol is working with me on this so hopefully it's ok to interject]

On Wed, Dec 15, 2021 at 3:40 PM Kent Mcleod <[email protected]> wrote:

> On Thu, Dec 16, 2021 at 1:20 AM <[email protected]> wrote:
> >
> > Hi All,
> >
> > We’ve been working on reviving the sel4-sys Rust crate and getting it
> usable again. Currently, we have it working correctly with RISC-V, we’re
> working on ARM (including aarch64) and X86. We’d like to contribute this
> work, but to have it landed we need to extend the test suite to include
> crate tests - especially the syscalls API.
> >
> > During the build, the crate generates the syscalls functions accessible
> from Rust code based on seL4 config.
> >
> > We use standard sel4test-tests suite to handle the tests:
> >
> > * We build the crate as static library
> > * Sel4test is built with `-DLibSel4FunctionAttributes=public` and while
> linking we overwrite the original symbols with the ones from a static
> library from the crate
> >
> > This allows us to run the standard test suite against Rust syscall stubs.
> >
> > For now the crate generates the syscall stubs with Rust flavor, so
> functions signatures between Rust and C do not match. To handle this we
> additionally generate a thin glue code adopting Rust signatures to the C
> ones.
> >
> > We generate the Rust syscalls with a slightly modified version of the
> `syscall_stub_gen.py` script - we copied it into the crate’s codebase.
> Copying the code doesn’t seem to be the best idea - we’d need to maintain
> the code in both places - seL4 kernel and the crate.
> >
> > We’d like to merge the Rust generator with the current set of tools - is
> this something you’d be willing to land in the kernel code? If not, how
> would you see the way forward here?
> >
>
> Hi,
> Thanks for making this proposal!
>
> Rust syscall binding support is something that we'd like to support.
> Are you able to make a pull-request with the changes to
> `syscall_stub_gen.py`? Depending on the changes we'd probably be happy
> to merge them upstream.
>

The current code hacks Rust in as a parallel branch to C (i.e. throughout
the code there are "if C then elif Rust then..."). Karol wants to
restructure the python to cleanly support multiple languages before
submitting.


> Do you also hope to merge the sel4test changes upstream? I think this
> would require more discussion as the sel4-sys crate was created by the
> Robigalia project and isn't maintained by the seL4 foundation so we
> wouldn't be able to easily maintain that functionality to keep the new
> parts of sel4test working.
>

Yes, that is a goal too. Ideally we'd like Rust support to track seL4
kernel changes.  Note the scope of sel4-sys is growing as it gets pulled in
for more uses and some decisions I made may be controversial (e.g. I've
made Rust api bindings return a new seL4_Result instead of seL4_Error).

>
>
> > Thanks and best regards
> > Karol
> > _______________________________________________
> > Devel mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> _______________________________________________
> Devel mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
Devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to