search

rust-osdev / bootimage

Tool to create bootable disk images from a Rust OS kernel.
Apache License 2.0
767 stars 67 forks source link

cargo xtest doesn't work under WSL1 with native QEMU #57

Open vlovich opened 4 years ago

vlovich commented 4 years ago
  1. Install QEMU natively on Windows
  2. Under WSL setup cargo
  3. In ~/bin/qemu-system-x86_64 put exec /mnt/c/Program\ Files/qemu/qemu-system-x86_64.exe "$@" and make the file executable
  4. run cargo xrun
  5. run cargo xtest

The xrun command works because it provides a relative path to the target to run to qemu. However xtest fails because it provides an absolute path which native QEMU doesn't understand. Passing a relative path just like xrun does should fix the issue.

Running: `qemu-system-x86_64 -drive format=raw,file=/mnt/c/projects/blog_os/target/x86_64-blog_os/debug/deps/bootimage-blog_os-f9b6181f9decdfac.bin -device isa-debug-exit,iobase=0xf4,iosize=0x04 -serial stdio -display none`
C:\Program Files\qemu\qemu-system-x86_64.exe: -drive format=raw,file=/mnt/c/projects/blog_os/target/x86_64-blog_os/debug/deps/bootimage-blog_os-f9b6181f9decdfac.bin: Could not open '/mnt/c/open/blog_os/target/x86_64-blog_os/debug/deps/bootimage-blog_os-f9b6181f9decdfac.bin': The system cannot find the path specified.
phil-opp commented 4 years ago

This seems to be an issue of the bootimage tool and not of cargo-xbuild. Let me try to transfer the issue to the bootimage repository.

phil-opp commented 4 years ago

Which version of bootimage are you using? Does the issue also occur on the latest version (0.8.0)?

I think the absolute path is obtained through the Path::canonicalize function of the standard library. It would be very unfortunate if that method really returns an invalid path…

vlovich commented 4 years ago

This is with 0.8.0

phil-opp commented 4 years ago

I looked into this a bit more and I think that this behavior comes from cargo itself. For cargo xrun, cargo invokes the runner executable with a relative path. You can see this when executing cargo xrun --verbose and looking at the line just before the "Building bootloader" message:

Running `bootimage runner target/x86_64-blog_os/debug/blog_os`

We see that cargo invokes the bootimage tool with a relative path to the binary.

For cargo xtest --verbose, we see that cargo passes absolute paths for test executables, e.g.:

Running `bootimage runner /home/username/blog_os/post-01/target/x86_64-blog_os/debug/deps/blog_os-7e5190da4ac3ce5c`

So we don't do anything special with these paths in bootimage. It's cargo itself that passes relative paths for normal runs and absolute paths for test binaries. Unfortunately, this also means that we can't really do anything to "fix" this in bootimage.

As a side note, I don't think that cargo's behavior is problematic. If your system environment cannot deal with absolute paths this sounds more like a problem of the environment. I would expect that there is some way to translate WSL paths to native Windows paths. Maybe it's possible to do such a translation in your ~/bin/qemu-system-x86_64 before invoking the native QEMU executable?