Cross with managed volumes

[jamesmunns]

Hey @japaric, this is a not-yet-ready-to-merge branch, but I'd like to get your feedback on it. I'm happy to spend time cleaning this up, but I have the "big picture" functionality in place (or at least I think so).

Putting out some known negatives first:

• I removed a lot of stuff. I could definitely use guidance to make sure I didn't accidentally cut out something important, particularly everything regarding interpreter.rs.
• I have not tested this outside of Linux yet. I tried with a VM, but docker doesn't run there, so I will need a physical machine. I should have access to one this week.
• I have not implemented a cap on the number of environments, or any kind of "garbage collection".
• Lots of documentation will need to be updated, and I expect all of the tests to break.
• Some behavior is probably not consistent to respecting flags and environment variables that should override/set behavior.

Some positives:

• This worked really well with my limited testing (basically cross compiling cross itself to different targets with different toolchains, entirely dockerized, and including cross run)
• Theoretically, this should have no environmental dependencies (other than Docker), so users could now get a precompiled binary of cross, and be compiling/cross compiling with no rust environment installed at all. Still needs to be tested/verified.
• Theoretically, this should work on OSX/Windows now, as long as they have Docker.
• It was not necessary to modify any of your existing docker images. The rust toolchain just comes from somewhere else now.

If you'd like to test this locally, there is one manual step required, you will have to build the volume manager image locally, with docker build -t volmgr -f ./volume_manager/Dockerfile ./volume_manager from the root of the repository. This step is only necessary once (or if you modify something in <crate root>/volume_manager.

[jamesmunns]

NOTE: cross rustup instead of garbage collection?

[jamesmunns]

NOTE: Only one copy of the registry.

[homunkulus]

☔ The latest upstream changes (presumably #138) made this pull request unmergeable. Please resolve the merge conflicts.

[homunkulus]

☔ The latest upstream changes (presumably #157) made this pull request unmergeable. Please resolve the merge conflicts.

[dvc94ch]

cc me

[dvc94ch]

So the first two commits work for me, I'm not sure about the rest, had some trouble but can retest.

Why is Cross.toml required?

[jamesmunns]

@dvc94ch at least from a first skim, I need somewhere to specify what the toolchain to use is, similar to how you do this:

cargo +nightly build

This allows you to set the version of rust used to build in this instance (since it is decoupled from your host environment), so you could select stable, nightly, nightly-2018-02-01 etc.

[jamesmunns]

We probably could "steal" the cargo syntax, and take it on the command line instead of a config file, which might be better UX anyway. I don't think I knew about that syntax while I was writing this PR.

[dvc94ch]

This allows you to set the version of rust used to build in this instance (since it is decoupled from your host environment), so you could select stable, nightly, nightly-2018-02-01 etc.

Yes, but I prefer having a reasonable default, and add a Cross.toml if I want to change the default.

I also like the cli method...

[jamesmunns]

Yeah, I would say CLI is preferred, or you can optionally make a cross.toml if you want it to be "persistent", or checked in. I would suggest stealing that code from Cargo.

I probably won't have time to work on this until at least this weekend (working on svd2rust in my existing free time), but feel free to ping me via here, IRC, or email (or we can set up a video chat) if you want to take over or understand what/why I did something.

[jamesmunns]

@dvc94ch I added support for the cross +nightly-2018-02-01 syntax, any chance you could hop on IRC (#rust-embedded) to discuss what you need?

I also would like to understand how to integrate a self-built rustc and/or cargo.

[dvc94ch]

I wrote on IRC, not sure if you got it. I'm reposting here in case you haven't seen it.

I'm not sure what I need yet. I've been distracted lately with some sideprojects. I told japaric I'd PR Rust's llvm - which may solve the problem entirely and see how much resistance there is. getting the PR merged is worthwhile for cross regardless... :)

[dvc94ch]

Looks like we need an embedded rust http server for distributing target specific toolchains and then we can pass RUSTUP_DIST_ROOT to load the toolchain from there.

cc @japaric @dylanmckay @pftbest

[dvc94ch]

@jamesmunns here's a custom rust release in case you are still playing around with this:
https://github.com/riscv-rust/rust/releases/tag/riscv-rust-1.26.0-1-dev

[dvc94ch]

@jamesmunns:
After checking out the latest branch and running:

cargo install --force
docker build -t volmgr  ./volume_manager
cross +stable build

I get this:

Skipping Xargo install...
Targeting stable x86_64-unknown-linux-gnu
sh: 6: rustup: not found
sh: 9: rustup: not found
sh: 1: cargo: not found

[Dylan-DPC-zz]

@jamesmunns any updates on this?

[jamesmunns]

@Dylan-DPC This was generally a PoC, though worked for at least basic use cases on Linux at least last time I tested it. If there is interest in it, I can try to freshen it up, it would be nice to have at least one person willing to test on Windows, I have a Mac and Linux PCs to test with (it needs to be an actual machine that can run a docker service, or a VM that supports virtualization from the guest, which doesn't include QEMU or VirtualBox, last I checked).

[Dylan-DPC-zz]

@jamesmunns not sure. you will have to discuss this with the others whether it is a good idea to go forward with this or not.

[dignifiedquire]

This would be great to have, I have both mac and windows machines here that I could help test on

[dignifiedquire]

I found a fix for the rustup not found issue. It seems docker really wants that mount directory to end in a slash so this change, in src/volume.rs, fixes the problem for me on my mac.

-    let base_mapping = format!("{}:/volwork", &base_path);
+    let base_mapping = format!("{}/:/volwork", &base_path);

[dignifiedquire]

I just ran tests on my mac with this against --target aarch64-linux-android 🎉

[Disasm]

What is the current status of this PR?

[dignifiedquire]

any update, happy to help, but this would be really useful

[jamesmunns]

Closing this, as it is very stale, and unlikely to happen as-is.