On Thu, Dec 16, 2021 at 11:36 AM Sam Leffler <[email protected]> wrote: > > [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. >
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. >> >> 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" >> >> >> >> > 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]
