Skip to content
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
Merged

Add support for the rumprun unikernel #28593

merged 1 commit into from
Sep 26, 2015

Conversation

gandro
Copy link
Contributor

@gandro 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
Copy link
Collaborator

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
Copy link
Member

nrc commented Sep 22, 2015

r? @alexcrichton

@rust-highfive rust-highfive assigned alexcrichton and unassigned nrc Sep 22, 2015
@@ -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,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How come this was added?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

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

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

@gandro
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
Copy link
Contributor

brson commented Sep 23, 2015

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

@brson
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
Copy link

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
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
Copy link
Member

@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
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
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
Copy link
Contributor Author

gandro commented Sep 26, 2015

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

@alexcrichton
Copy link
Member

@bors: r+ c099cfa

Thanks!

@bors
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
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 bors merged commit c099cfa into rust-lang:master Sep 26, 2015
@brson brson added the relnotes Marks issues that should be documented in the release notes of the next release. label Oct 2, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Marks issues that should be documented in the release notes of the next release.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants