Add support for the rumprun unikernel #28593

gandro · 2015-09-22T21:19:21Z

This adds a new target, x86_64-rumprun-netbsd, and related changes to std.

Rumprun is a unikernel platform that provides a POSIX-y interface. For the most part, rumprun uses NetBSD's libc and drivers, therefore target_os is netbsd. However, being a unikernel, rumprun does not support process management, signals or virtual memory, so related functions might fail at runtime. For this reason, stack guards are disabled in std.

To support conditional compilation, target_env is set to rumprun. Maybe target_vendor would be technically more fitting, but it doesn't seem to be worth the hassle.

Code for rumprun is always cross-compiled, it uses always static linking and needs a custom linker. The target makes use of the newly introduced no_default_libs flag, as the rumprun linker will otherwise not use the correct search path.

rust-highfive · 2015-09-22T21:19:39Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nrc (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

nrc · 2015-09-22T21:20:27Z

r? @alexcrichton

alexcrichton · 2015-09-22T23:36:05Z

src/librustc_back/target/windows_msvc_base.rs

@@ -53,6 +53,7 @@ pub fn opts() -> TargetOptions {
        exe_suffix: ".exe".to_string(),
        staticlib_prefix: "".to_string(),
        staticlib_suffix: ".lib".to_string(),
+        no_default_libraries: false,


How come this was added?

The rumprun linker wrapper uses a GCC spec file to add a path to the rumprun version of system libraries (libc, libpthread etc). If -nodefaultlibs is specified, gcc will not use specified the path.

Maybe @mato has more insight to this, he helped me debug the issue.

Oh. I completely missed that fact that this is a Windows target. This has nothing to do with rumprun, I will remove it. Sorry about that.

This slipped in from my previous patch. I ommited it in the final version, because the mvc linker doesn't include default libraries anyway.

alexcrichton · 2015-09-22T23:37:48Z

Thanks! Pretty neat seeing Rust run on all these new platforms!

Is x86_64-rumprun-netbsd the official target? (just confirming)

gandro · 2015-09-22T23:56:48Z

Yes, x86_64-rumprun-netbsd is the official target, also used for cross-compiling C programs. There was a thread on the gcc mailing list about the rationale behind this triple: https://gcc.gnu.org/ml/gcc/2015-03/msg00350.html ( Follow up: https://gcc.gnu.org/ml/gcc/2015-04/msg00033.html )

In the future, rumprun might offer other ABIs than NetBSDs, this is why conditional compilation always checks for both, target_env = rumprun and target_os = netbsd.

brson · 2015-09-23T00:39:09Z

Exciting platform. What are your ambitions for Rust rump kernels? Any solid plans yet?

brson · 2015-09-23T00:42:02Z

hm, let's be wary of making target_env a grab bag. The existing uses seem to be different than this one. Compare x86_64-pc-windows-gnu / gnu and x86_64-rumprun-netbsd / rumprun. The env (a term we made up) is in different positions in the triple.

What is target_env? Is it just some random metadata that can be used to disambiguate platforms?

anttikantee · 2015-09-23T01:38:19Z

On 23/09/15 00:39, Brian Anderson wrote:

Exciting platform. What are your ambitions for Rust rump kernels? Any solid plans yet?

I hope you do not mind me interjecting as the Cerberus for nomenclature.
When people first hear about rump kernels, they're slammed with a
bunch of new terminology which is easy to mix up, especially since the
terminology hasn't established itself in common lingo. So, my
motivation here is to politely advance establishing that lingo.

A rump kernel is built from [monolithic] kernel driver components with
the rest of the kernel simply not included. Why? 1) full-blown OS
kernels are the only places with truly working drivers 2) the
1960's-relevant bits of said kernels are of diminishing relevance in
2010's. So, "Rust rump kernel", at least to me (and I did coin the term
"rump kernel"), would imply that you have an OS kernel written in Rust
with some irrelevant bits that you want to leave out from your stack.
Since you'd be writing your hypothetical OS now'ish, it would be silly
to design it as a 1960's time-sharing OS, and therefore you wouldn't
need to throw those bits out. Besides, writing real-world compatible
set of drivers will not happen overnight no matter how good the language
is (because the world is broken ;). Hope that made sense.

With that out the way, the question about intersection points between
Rumprun unikernels and Rust might be interesting to discuss in a forum
beyond this pull req.

gandro · 2015-09-23T12:07:29Z

@brson I can add target_vendor. Might be worth it, for example if rumprun ever grows the ability to host musl (currently seems very unlikely to me, but who knows) we might want to differentiate between target_vendor and target_env.

I can give target_vendor a shot. What should target_vendor be set to for the existing targets? Should it be empty? Should it be "unknown"?

alexcrichton · 2015-09-23T16:41:22Z

@brson

What is target_env? Is it just some random metadata that can be used to disambiguate platforms?

I took this name from LLVM's EnvironmentType enum as it was where GNU vs MSVC was disambiguated

@gandro

Yeah target_vendor is probably the best option. You'll probably want to gate it by default for now (e.g. require #![feature(target_vendor)] to use it, and most of the existing triples will be unknown but the OSX ones at least will be apple

gandro · 2015-09-24T01:03:52Z

I will rebase this to use target_vendor once PR #28612 lands (hopefully).

@alexcrichton

This adds a new target property, `target_vendor`. It is to be be used as a matcher for conditional compilation. The vendor is part of the [autoconf target triple](http://llvm.org/docs/doxygen/html/classllvm_1_1Triple.html#details): `<arch><sub>-<vendor>-<os>-<env>`. `arch`, `target_os` and `target_env` are already supported by Rust. This change was suggested in PR #28593. It enables conditional compilation based on the vendor. This is needed for the rumprun target, which needs to match against both, target_os and target_vendor. The default value for `target_vendor` is "unknown", "apple" and "pc" are other common values. Matching against the `target_vendor` is introduced behind the feature gate `#![feature(cfg_target_vendor)]`. This is the first time I messed around with rustc internals. I just added the my code where I found the existing `target_*` variables, hopefully I haven't missed anything. Please review with care. :) r? @alexcrichton

For most parts, rumprun currently looks like NetBSD, as they share the same libc and drivers. However, being a unikernel, rumprun does not support process management, signals or virtual memory, so related functions might fail at runtime. Stack guards are disabled exactly for this reason. Code for rumprun is always cross-compiled, it uses always static linking and needs a custom linker.

gandro · 2015-09-26T12:14:34Z

Rebased to use target_vendor. Also doesn't change the MSVC target anymore.

alexcrichton · 2015-09-26T18:00:13Z

@bors: r+ c099cfa

Thanks!

bors · 2015-09-26T18:21:17Z

⌛ Testing commit c099cfa with merge c9c7908...

This adds a new target, `x86_64-rumprun-netbsd`, and related changes to `std`. Rumprun is a unikernel platform that provides a POSIX-y interface. For the most part, rumprun uses NetBSD's libc and drivers, therefore `target_os` is `netbsd`. However, being a unikernel, rumprun does not support process management, signals or virtual memory, so related functions might fail at runtime. For this reason, stack guards are disabled in `std`. To support conditional compilation, `target_env` is set to `rumprun`. Maybe `target_vendor` would be technically more fitting, but it doesn't seem to be worth the hassle. Code for rumprun is always cross-compiled, it uses always static linking and needs a custom linker. The target makes use of the newly introduced `no_default_libs` flag, as the rumprun linker will otherwise not use the correct search path.

bors · 2015-09-26T20:06:49Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt

rust-highfive assigned nrc Sep 22, 2015

rust-highfive assigned alexcrichton and unassigned nrc Sep 22, 2015

alexcrichton reviewed Sep 22, 2015
View reviewed changes

gandro mentioned this pull request Sep 24, 2015

rustc: Add target_vendor for target triples #28612

Merged

gandro force-pushed the rumprun branch from 78234eb to c099cfa Compare September 26, 2015 12:11

bors merged commit c099cfa into rust-lang:master Sep 26, 2015

gandro mentioned this pull request Sep 26, 2015

Add Makefile for Rust, cargo and cargo-rumpbake rumpkernel/rumprun-packages#15

Merged

brson added the relnotes Marks issues that should be documented in the release notes of the next release. label Oct 2, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for the rumprun unikernel #28593

Add support for the rumprun unikernel #28593

gandro commented Sep 22, 2015

rust-highfive commented Sep 22, 2015

nrc commented Sep 22, 2015

alexcrichton Sep 22, 2015

gandro Sep 22, 2015

gandro Sep 26, 2015

alexcrichton commented Sep 22, 2015

gandro commented Sep 22, 2015

brson commented Sep 23, 2015

brson commented Sep 23, 2015

anttikantee commented Sep 23, 2015

gandro commented Sep 23, 2015

alexcrichton commented Sep 23, 2015

gandro commented Sep 24, 2015

gandro commented Sep 26, 2015

alexcrichton commented Sep 26, 2015

bors commented Sep 26, 2015

bors commented Sep 26, 2015

Add support for the rumprun unikernel #28593

Add support for the rumprun unikernel #28593

Conversation

gandro commented Sep 22, 2015

rust-highfive commented Sep 22, 2015

nrc commented Sep 22, 2015

alexcrichton Sep 22, 2015

Choose a reason for hiding this comment

gandro Sep 22, 2015

Choose a reason for hiding this comment

gandro Sep 26, 2015

Choose a reason for hiding this comment

alexcrichton commented Sep 22, 2015

gandro commented Sep 22, 2015

brson commented Sep 23, 2015

brson commented Sep 23, 2015

anttikantee commented Sep 23, 2015

gandro commented Sep 23, 2015

alexcrichton commented Sep 23, 2015

gandro commented Sep 24, 2015

gandro commented Sep 26, 2015

alexcrichton commented Sep 26, 2015

bors commented Sep 26, 2015

bors commented Sep 26, 2015