Uh oh!
There was an error while loading. Please reload this page.
Redesign the interface to the unikernel HermitCore - #65167
Conversation
- the old interface between HermitCore and the Rust Standard Library based on a small C library (newlib) - remove this interface and call directly the unikernel - remove the dependency to the HermitCore linker - use rust-lld as linker
JohnCSimon
commented
Oct 12, 2019
Ping from triage |
varkor
commented
Oct 12, 2019
alexcrichton
commented
Oct 15, 2019
Thanks for the PR @stlankes! This is quite a large amount of code coming in, but it looks like it's all in the Can you speak a little about this target, why it's being included in libstd, why it has a new directory for support, and what its maintenance story will look like going forward? |
@alexcrichton, you are right. Maybe I should explain our motivation. I am part of a research group for system software at a german university and use Rust in my operating system classes. We want to maintain and extend this part of libstd. The unikernel HermitCore is one of our projects. Unikernels are specialized, single-address-space machine images. Such kernels are typically used in the area of cloud computing. They shrink the attack surface and resource footprint of cloud services. The best known unikernel is maybe MirageOS. We already developed a version of HermitCore, which is part of libstd. However, it is mixture of C and Rust. Our objective is to remove C completely from our toolchain. C is in our opinion not valid to develop secure applications. The current version is only working within our hypervisor uhyve. A prototype is already working with @phil-oppbootimage, which converts a kernel into a valid boot image. Consequently, it runs on common hypervisors like qemu. A network is currently missing. We have also a prototype, which uses smoltcp as network stack. But it isn’t in a state to publish it. So, we have something in our pipeline. The current patch is already huge. This is our motivation to publish the current version and smaller extensions later. I hope that I have explained our motivation well. |
alexcrichton
commented
Oct 18, 2019
Ok thanks for the info! As I mentioned before we don't really have strict policies right now one way or another about how to organize libstd. It's generally left up to the reviewer and a few defacto ways that we manage a separate target in libstd. For example:
If that all sounds good, I'll review the integration points here and can r+ |
It is fine for me! Thanks for the support! |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| __variant1, | ||
| #[doc(hidden)] | ||
| __variant2, | ||
| } |
There was a problem hiding this comment.
Would it be possible to move these implementations to libc?
There was a problem hiding this comment.
It is already in libc. I forgot only to remove my workaround. I will fix it.
stlankes
commented
Oct 18, 2019
@alexcrichton I follow your suggestions and revise my code. |
rust-highfive
commented
Oct 18, 2019
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
=> simplifies the maintenance of the interface
stlankes
commented
Oct 20, 2019
@alexcrichton Okay, I guess I was naive. I moved the C interface to special crate to simplify the maintenance. The crate isn't part of the whitelist. Do you add it on the whitelist or should I revert the last commit? |
rust-highfive
commented
Oct 20, 2019
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
alexcrichton
commented
Oct 21, 2019
Yes adding that to the whitelist should be fine, most new targets in Rust nowadays end up taking this strategy of moving the very low-level support to a separate crate that libstd then uses. |
rust-highfive
commented
Oct 21, 2019
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
bors
commented
Oct 26, 2019
⌛ Testing commit 805a330 with merge 5fa0e21b87fc68617b3bb0abd9288deef1b7e632... |
rust-highfive
commented
Oct 26, 2019
Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
bors
commented
Oct 26, 2019
💔 Test failed - checks-azure |
@alexcrichton What does the test failed? |
JohnTitor
commented
Oct 26, 2019
It's a network error. |
bors
commented
Oct 26, 2019
Redesign the interface to the unikernel HermitCore We are developing the unikernel HermitCore, where the kernel is written in Rust and is already part of the Rust Standard Library. The interface between the standard library and the kernel based on a small C library. With this pull request, we remove completely the dependency to C and use lld as linker. Currently, the kernel will be linked to the application as static library, which is published at https://github.com/hermitcore/libhermit-rs. We don’t longer support the C interface to the kernel. Consequently, we remove this part from the Rust Standard Library.
bors
commented
Oct 26, 2019
☀️ Test successful - checks-azure |
add basic HermitCore support within libtest This an extension to rust-lang#65167. The current pull request extend libtest to support HermitCore as target OS.
stlankes
commented
Oct 31, 2019
@alexcrichton Naive question. I need for my toolchain |
alexcrichton
commented
Oct 31, 2019
Ah sorry, I'm not quite sure, I haven't used that config option much myself. |
stlankes
commented
Oct 31, 2019
@alexcrichton No problem! |
stlankes
commented
Nov 16, 2019
@alexcrichton I have a version of RustyHermit, where I include my libos as crate instead of a static library. In this case, I am able to call directly Rust code from my kernel (e.g https://github.com/hermitcore/rust/blob/with-hermit/src/libstd/sys/hermit/mutex.rs#L12). However, I have to modify a few helper creates (log, rust-x86, rust-cupid,...). For instance, I modified log. Do you think that this a good idea? Can this be part of libstd? |
alexcrichton
commented
Nov 18, 2019
I think we'll want to continue to be pretty conservative with dependencies of the standard library, so we don't have a great way of adding new dependencies to libstd for third-party targets at this time unfortunately. |
stlankes
commented
Nov 18, 2019
No problem. I was expecting the answer.... |
Hermit: Remove floor symbol This symbol should be provided by Hermit. It was introduced in 2019 (rust-lang#65167). Since 2020, Hermit provides these math functions on its own (hermit-os/hermit-rs#37). I think moving this to Hermit was merely an oversight. Related: * hermit-os/kernel#654 * hermit-os/hermit-rs#406 CC: `@stlankes`
Hermit: Remove floor symbol This symbol should be provided by Hermit. It was introduced in 2019 (rust-lang/rust#65167). Since 2020, Hermit provides these math functions on its own (hermit-os/hermit-rs#37). I think moving this to Hermit was merely an oversight. Related: * hermit-os/kernel#654 * hermit-os/hermit-rs#406 CC: `@stlankes`
We are developing the unikernel HermitCore, where the kernel is written in Rust and is already part of the Rust Standard Library. The interface between the standard library and the kernel based on a small C library. With this pull request, we remove completely the dependency to C and use lld as linker. Currently, the kernel will be linked to the application as static library, which is published at https://github.com/hermitcore/libhermit-rs.
We don’t longer support the C interface to the kernel. Consequently, we remove this part from the Rust Standard Library.