Porting QEMU to RedoxOS | Hacker News Reader

Porting QEMU to RedoxOS

redox-os.org

123 pointsrvz23 comments

QEMU build system guy here. If you have any questions about the configure and meson scripts, you can catch me on the #qemu channel on OFTC.

Of the features you disabled, the main one to be reinstated seems to be slirp.

--enable-tools builds qemu-img, qemu-nbd and other tools. --enable-coroutine-pool is an optimization that should not be a problem for portability.

If only I understood how to use QEMU in practice. Are there any tutorials that come with all the parts necessary to get something actually running (and explaining it), without me having to go off in search for missing components that I have no idea where to find?

QEMU is complicated. You're probably better off using virt-manager, it provides a GUI front-end and also improves on security by using libvirt (with support for SELinux or AppArmor).

Drew DeVault has a nice introduction[1]. ArchWiki has coverage on the many options not mentioned[2].

[1] https://drewdevault.com/2018/09/10/Getting-started-with-qemu...

[2] https://wiki.archlinux.org/title/QEMU

It depends what you want to do. When QEMU is used for virtualization it's typically a component in a larger stack like GNOME Boxes or virt-manager, two UIs that rely on libvirt to run QEMU.

When QEMU is used for emulating ARM boards or retro computing you can launch it from the command-line specifying just a few things like the path to a disk image file or the amount of RAM. There are a lot of command-line options and it can be overwhelming, but luckily they are usually not needed for these use cases.

Documentation is here but it's easier to start with a QEMU command-line recommended by the software (e.g. exotic OSes) you want to try out: https://qemu-project.gitlab.io/qemu/

A remarkably simpler use case is if you want to run Linux programs built for a different architecture (instead of using QEMU to boot into a system). QEMU can do this on its linux-userspace configuration. The only knob you really have to know about is QEMU_LD_PREFIX environment variable if your executable has dynamic dependencies (C library, e.g.).

Along with the other good responses in this thread from bonzini and others, you might want to also check out this[1] response. It talks about useful command-line tools for KVM- and QEMU-based virt.

[1] https://news.ycombinator.com/item?id=26993381

-kernel linux -initrd somebusybox.cpio -m 64

There you go.

Yes, email qemu-devel@nongnu.org or discuss with developers on the #qemu IRC channel on chat.oftc.net if you hit issues.

QEMU builds on a number of host operating systems, not all of them POSIX. We'd be happy to help!

Thank you for the information/tip. It would be great to have occasional support from the #qemu community too! (BTW, I am Enygmator, the author of the post)

Thanks a lot! (I am Enygmator, the author of the post) I find it so heartening to discover that there's #qemu on oftc. I will most certainly contact you on oftc, as having someone to help me make sense of QEMU (once in a while) would be great! P.S.: I didn't know anything about OFTC until today. I am an amateur.

What an awesome Summer of Code project! I wish opportunities had been around when I was learning to program. I remember constantly looking for open source projects to contribute to, but each had such a high bar for entry that there was no low-hanging-fruit that I could cherry-pick (sic) to get involved.

While it's certainly useful to learn by rolling projects from the ground up, you can learn a whole lot more by contributing to an established project and experiencing how their code standards, review process, etc. all feel in comparison to other projects. One big thing I lacked was simply having someone say "We write static functions LIKE THIS because they have THAT ROLE within the scope of this project."

>I wish opportunities had been around when I was learning to program.

And yet now, we have plenty of projects and nobody contributing.

https://github.com/redox-os/redox/graphs/contributors

This graph doesn't look so healthy. Projects with one major contributor tend to die the moment that contributor loses interest.

Which leads me to wonder, if rust is so popular, and this is one of the most relevant rust projects in the wild, why is this essentially a single contributor repo? Linus didn't write Linux by himself. Redox is never going to happen with a single developer.

Doesn't anyone want a memory safe OS and micro kernel? What does this say about the demand for memory safe systems languages?

Rust's learning curve is a wall, there is little doubt about it [1]. I am well aware people love to hate on C++ but compare to another (even younger) operating system project written in a more mainstream language: https://github.com/serenityos/serenity/graphs/contributors

[1] An example I like, try to make sense of this https://cosmic.mearie.org/2014/01/periodic-table-of-rust-typ...

Just curious, because I'd love to run redox for real one day :D, Is the biggest issue around real hardware support the drivers/firmware? Would it make sense / be possible to reuse the Linux code?

The biggest issue _I_ had as a user was getting redox to compile itself.

It is fun as a toy but developing on it is difficult.

Or I missed something.

Yeah, I looked into it in the past couple of months. Ultimately it wouldn't compile because my system has GCC 11. They have a vendored copy of ring that's about 2 years out of date, and has some issue with array type confusion where a field is defined as a fixed length array in one field and a pointer in the other. Since GCC 11, that's been a warning, and their build system compiles their fork of ring with -Werror, so that new warning in GCC 11 breaks the build.

Sadly their gitlab instance at the time was "email the dev to set up an account", so I just left it there.

> Sadly their gitlab instance at the time was "email the dev to set up an account", so I just left it there.

The Gitlab had a "sign in with Github" feature at least since August 2019, which is when I created my account there.

Well you ignored my question, if that counts as something.

Well the answer is no, you can't reuse kernel drivers and, no, that isn't the biggest barrier to adoption. Which is what I'm responding to.

The biggest barrier to adoption is lack of a working compiler.

> Would it make sense / be possible to reuse the Linux code?

Linux is GPL-2.0 while RedoxOS is MIT licensed. You can't use Linux driver code without relicensing Redox as GPL-2.0.

What you can do, however, is implement a Linux driver compatibility layer. Linux has NDISwrapper, which enables Linux to take advantage of Windows drivers for networking hardware. FreeBSD has Linux compatibility with linuxkpi and FreeBSD can use some Linux graphics drivers that way.

You can also port the drivers and keep them out of Redox's MIT source tree, too.

If you want to add drivers to Redox, you can do a clean room implementation by documenting how Linux interacts with the hardware it supports, and then writing drivers from those documents.

is POSIX on the roadmap for redox or are they intentionally avoiding that? (to encourage more experimentation and ground up in-rust software development)

i've been watching with interest for a while, there's a lot to like about this project!

From https://doc.redox-os.org/book/ch01-03-our-goals.html

>"The non-goals of Redox"

>"We are not a Linux clone, or POSIX-compliant, nor are we crazy scientists, who wish to redesign everything. Generally, we stick to well-tested and proven correct designs. If it ain't broken don't fix it."

>"This means that a large number of standard programs and libraries will be compatible with Redox. Some things that do not align with our design decisions will have to be ported."

>"The key here is the trade off between correctness and compatibility. Ideally, you should be able achieve both, but unfortunately, you can't always do so."

Reply on news.ycombinator.com