sel4-sys support

older
Re: seL4 developer hangout/video...

kgugala＠antmicro.com

16 Dec 2021 16 Dec '21

1:15 a.m.

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? Thanks and best regards Karol

Show replies by date

Kent Mcleod

16 Dec 16 Dec

10:36 a.m.

On Thu, Dec 16, 2021 at 1:20 AM 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. 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.

...

Thanks and best regards Karol _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems

Sam Leffler

11:36 a.m.

[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 wrote:

...

On Thu, Dec 16, 2021 at 1:20 AM 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 -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems

Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems

Kent Mcleod

12:14 p.m.

On Thu, Dec 16, 2021 at 11:36 AM Sam Leffler 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 wrote:

...
On Thu, Dec 16, 2021 at 1:20 AM 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 -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems

Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems

Sam Leffler

1:28 p.m.

On Wed, Dec 15, 2021 at 5:14 PM Kent Mcleod wrote:

...

On Thu, Dec 16, 2021 at 11:36 AM Sam Leffler 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

...
...
On Thu, Dec 16, 2021 at 1:20 AM 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

...
...
...
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

...
...
...
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.

wrote: library from the crate the code in both places - seL4 kernel and the crate. 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.

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@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems

Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems

Jimmy Brush

10:37 p.m.

Hello, I am a member of the Robigalia project. If you'd like to discuss anything with us you're welcome to join us in our matrix room at https://matrix.to/#/#robigalia:matrix.org or the linked IRC room at OFTC #robigalia. I'm glad you found our project useful! We have abandoned our old code because we felt maintaining a separate version of the libsel4 python build scripts to generate rust was impractical for our project. We found it to be very difficult to keep in sync with seL4 changes. While upstreaming this work is one solution, it just pushes the maintenance burden upstream. We think a better solution is to improve the seL4 build system itself to make it easier to add language bindings, not just for rust but for any language. To that end, we believe expanding the scope of the IDL so that libsel4 can be completely procedurally generated from it is the right thing to do. After that is done, I think it would make more sense to work on upstreaming something like this. We have been experimenting with our own complete seL4 IDL and exploring generating a rust seL4 library from it and intend to share our findings. So far I believe a seL4 IDL will significantly reduce the amount of code, complexity, and maintenance burden of the libsel4 build system, since it removes the need to hard code the information about types, sizes, names, etc that currently exists in the python scripts. Thanks, JB

1110

Age (days ago)

1111

Last active (days ago)

List overview

Download

5 comments

4 participants

participants (4)

Jimmy Brush
Kent Mcleod
kgugala＠antmicro.com
Sam Leffler

sel4-sys support

kgugala＠antmicro.com

Kent Mcleod

Sam Leffler

Kent Mcleod

Sam Leffler

Jimmy Brush

tags

participants (4)