Skip to content

/rust

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for the rumprun unikernel #28593

Merged
merged 1 commit into from Sep 26, 2015

Conversation

Reviewers
No reviews
Assignees

@alexcrichton alexcrichton

Labels
relnotes
Projects
None yet
Milestone
No milestone
7 participants
@gandro @rust-highfive @nrc @alexcrichton @brson @anttikantee @bors
@gandro
Copy link
Contributor

gandro commented Sep 22, 2015

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 rust-highfive assigned nrc Sep 22, 2015

@rust-highfive

This comment has been minimized.

Sign in to view
Copy link
Collaborator

rust-highfive commented Sep 22, 2015

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

This comment has been minimized.

Sign in to view
Copy link
Member

nrc commented Sep 22, 2015

r? @alexcrichton

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

src/librustc_back/target/windows_msvc_base.rs Outdated
@@ -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,

This comment has been minimized.

Sign in to view
Copy link
@alexcrichton

alexcrichton Sep 22, 2015

Member

How come this was added?

This comment has been minimized.

Sign in to view
Copy link
@gandro

gandro Sep 22, 2015

Author Contributor

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.

This comment has been minimized.

Sign in to view
Copy link
@gandro

gandro Sep 26, 2015

Author Contributor

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

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Sep 22, 2015

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

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

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

gandro commented Sep 22, 2015

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

brson commented Sep 23, 2015

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

brson commented Sep 23, 2015

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

This comment has been minimized.

Sign in to view
Copy link

anttikantee commented Sep 23, 2015

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

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

gandro commented Sep 23, 2015

@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

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Sep 23, 2015

@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 gandro referenced this pull request Sep 24, 2015

Merged

rustc: Add target_vendor for target triples #28612

@gandro

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

gandro commented Sep 24, 2015

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

bors added a commit that referenced this pull request Sep 26, 2015

@bors
Auto merge of #28612 - gandro:targetvendor, r=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
Loading status checks…
78ce46f
@gandro
Add support for the rumprun unikernel 
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.
Loading status checks…
c099cfa

@gandro gandro force-pushed the gandro:rumprun branch from 78234eb to c099cfa Sep 26, 2015

@gandro

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

gandro commented Sep 26, 2015

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

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Sep 26, 2015

@bors: r+ c099cfa

Thanks!
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Sep 26, 2015

⌛️ Testing commit c099cfa with merge c9c7908...

bors added a commit that referenced this pull request Sep 26, 2015

@bors
Auto merge of #28593 - gandro:rumprun, r=alexcrichton 
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.
Loading status checks…
c9c7908
@bors

@bors bors merged commit c099cfa into rust-lang:master Sep 26, 2015
2 checks passed

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@gandro gandro referenced this pull request Sep 26, 2015

Merged

Add Makefile for Rust, cargo and cargo-rumpbake #15

@brson brson added the relnotes label Oct 2, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.