On Wed, Dec 15, 2021 at 5:14 PM Kent Mcleod <kent.mcleod72(a)gmail.com> wrote:
On Thu, Dec 16, 2021 at 11:36 AM Sam Leffler
[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 <kent.mcleod72(a)gmail.com>
> On Thu, Dec 16, 2021 at 1:20 AM <kgugala(a)antmicro.com> 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
> > 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
> > 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?
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
to restructure the python to cleanly support multiple languages before
A link to a public branch to look at would be fine initially too.
Just to check that there aren't any obvious incompatibility issues.
ATM the C support is unchanged; unless you specify the language as "Rust"
you get the same output.
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).
Does this mean you are expecting to publish your updates under the
sel4-sys crate on crates.io? Is that something that's already been
coordinated with the Robigalia project? The readme at the moment says
that it has been "yanked"
I defer to Karol on the logistics. As to the original crate I believe the
original author was contacted but hasn't (yet) responded. Their copyright
remains. We just want to share the work.
> > Thanks and best regards
> > Karol
> > _______________________________________________
> > Devel mailing list -- devel(a)sel4.systems
> > To unsubscribe send an email to devel-leave(a)sel4.systems
> Devel mailing list -- devel(a)sel4.systems
> To unsubscribe send an email to devel-leave(a)sel4.systems