wucke13
commented
5 months ago A further note: I checked, and currently indeed there are differences between the different header files per microkit target. The following shell snippet provides some rough overview:
find $MICROKIT_SDK -type f -name '*.h' -exec sh -c 'cd $(dirname {}); sha1sum $(basename {})' \; | awk '{printf("%-40s %s\n", $2, $1)}' | sort --uniqueOutstanding things with differences:
constants.hdeprecated.hfaults.hgen_config.hinvocation.hmapping.hobjecttype.hsel4_client.hsimple_types.hsyscalls.htypes_gen.htypes.h
nspin
Ivan-Velickovic
lsf37
Currently, I see 23 targets supported by microkit. Each of them has 3 different modes (
benchmark,debug&release). So overall, there are quite some variants of the API offered. To add upon that, the header files itself are polymorphic, as in they themselves contain macros to adapt for different target platforms, i. e. like this:I'm currently trying to make Rust bindings for microkit, as to support implementation of protection domains in Rust. While it is possible to just embrace this high adaptability of the API, I see a real danger that this will (and has in the past!) seriously hindered solid Rust support of microkit (and seL4 in the grander picture). In order to make my life easier (and the programming in Rust for microkit story nicer), I have a wishlist. I present various options, starting with the easy-to-implement-but-not-so-nice to the more-complex-to-implement-but-way-nicer-to-use.
$MICROKIT_SDKpathbuild.rsto dynamically generate the bindings$MICROKIT_SDKpathbuild.rsto dynamically generate the bindings$MICROKIT_SDKpathbuild.rsto dynamically generate the bindingsFrom a user point of view, 4. and 5. are by far the most preferable ones. Its the only option where a pure Rust toolchain, without any libclang/binding generator stuff gets executed on the end-developers machine. They just use the
microkit/microkit-syscrate offered on https://crates.io/ . Its also the only option if we want a robust ecoystem to be built on top ofmicrokit, because only with a stable API & ABI we can avoid spurious type change problems.With Option 4. however, considering that a significant portion of the microkit API is header only, we still would have to involve a C compiler to get a final ELF for the protection domain. Option 5. on the other hand takes C tooling completely out of the equation, we could then compile pure Rust code down to an ELF that is usable in microkit. Of course Option 5. is more work when the ABI changes, these change would have to be ported over to the Rust code by hand.
If offering a stable API & ABI is not possible (or not yet possible), option 3. is preferable. While we do force binding generation on to the end-developer, we can automate quite some stuff. This way we can get away with all the fuzz about different target boards and associated header files. Instead, the combination of the Rust profile (debug vs release) and the Rust target (i.e.
aarch64-unknown-none) completely determine which header files to pick.I totally understand, that likely asking for Option 5. is quite the ask at this early stage of microkit. However, getting at least to Option 3. would already considerable ease my pain in providing initial Rust support (and more significantly, ease the pain on making Rust libraries on top of microkit).
I'm looking forward for your feedback!