Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust in QEMU Roadmap

lore.kernel.org

Post reply on HN
Print view View original

11–20 of 184 posts

Re: Rust in QEMU Roadmap

#11

Post by bonzini »

aapoalas wrote: post #9
bonzini wrote: post #4

Earlier quoted context omitted.

Hello! Small world. :) For drivers, it's already happening, especially for graphics but not limited to that. 6.13 has some very important changes. A lot of Linux is drivers so that's already a reason to be bullish. Answering for QEMU instead: it depends on the community being willing to share the burden of writing the FFI code. Despite Rust being low level, there is still a substantial amount of work to do. Replies t…

Hello. I assume tracepoints mean kprobes/uprobes or something along those lines? I've just this weekend worked on implementing/adapting a crate for DTrace USDTs aka DTrace probes to also work on Linux and generate SystemTap SDTs (aka USDTs aka dtrace probes). This is probably a little different from tracepoints in the kernel space but I'm somewhat interested in going deeper and into the kernel side of things. Let me…

QEMU has several tracepoint providers, the main ones are (a slightly fancy version of) printf and USDT. There is a Python program that generates the C code for the chosen backend(s), so the thing to do would be to adjust the script to produce either an FFI bridge or the equivalent Rust code.

Re: Rust in QEMU Roadmap

#12

Post by JoshTriplett »

bonzini wrote: post #2

Thanks for posting this to HN! Author here, happy to answer any questions. (By the way, I did not originally start the project, though I've worked quite a bit on the safe abstractions that are mentioned in the roadmap).

What does your wishlist for Rust look like? (Besides "simpler C/Rust interoperability", of course.) Has QEMU run into things that Rust-for-Linux hasn't, that feel missing from the Rust language?

Re: Rust in QEMU Roadmap

#13

Post by bonzini »

JoshTriplett wrote: post #12
bonzini wrote: post #2

Thanks for posting this to HN! Author here, happy to answer any questions. (By the way, I did not originally start the project, though I've worked quite a bit on the safe abstractions that are mentioned in the roadmap).

What does your wishlist for Rust look like? (Besides "simpler C/Rust interoperability", of course.) Has QEMU run into things that Rust-for-Linux hasn't, that feel missing from the Rust language?

Right now the only language-level thing I would like is const operator overloading. Even supporting MSRV as old as 1.63 was not a big deal, the worst thing was dependencies using let...else which we will vendor and patch.

Pin is what it is, but it is mostly okay since I haven't needed projection so far. Initialization using Linux's "impl PinInit" approach seems to be working very well in my early experiments, I contributed changes to use the crate without unstable features.

In the FFI area: Bindgen support for toml configuration (https://github.com/rust-lang/rust-bindgen/pull/2917 but it could also be response files on the command line), and easier passing of closures from Rust to C (though I found a very nice way to do it for ZSTs that implement Fn, which is by far the common case).

The "data structure interoperability" part of the roadmap is something I should present to someone in the Rust community for impressions. Some kind of standardization of core FFI traits would be nice.

Outside the Rust core proper, Meson support needs to mature a bit for ease of use, but it is getting there. Linux obviously doesn't need that.

BTW, saw your comment in the dead thread, you're too nice. I have been curious about Rust for some time and with Linux maturing, and Linaro doing the first contribution of build system integration + sample device code, it was time to give it a try.

Re: Rust in QEMU Roadmap

#14

Post by pjmlp »

krnaxbl wrote: post #8
raggi wrote: post #6

Earlier quoted context omitted.

just wait until you see the real conspiracy

[flagged]

No need, Linux with extinguish by itself when the leadership that created it in first place is long gone.

It will certainly continue to exist in dozen forks, although nothing that will continue their vision.

Re: Rust in QEMU Roadmap

#15

Post by aapoalas »

bonzini wrote: post #11
aapoalas wrote: post #9

Earlier quoted context omitted.

Hello. I assume tracepoints mean kprobes/uprobes or something along those lines? I've just this weekend worked on implementing/adapting a crate for DTrace USDTs aka DTrace probes to also work on Linux and generate SystemTap SDTs (aka USDTs aka dtrace probes). This is probably a little different from tracepoints in the kernel space but I'm somewhat interested in going deeper and into the kernel side of things. Let me…

QEMU has several tracepoint providers, the main ones are (a slightly fancy version of) printf and USDT. There is a Python program that generates the C code for the chosen backend(s), so the thing to do would be to adjust the script to produce either an FFI bridge or the equivalent Rust code.

Can you link the script? This sounds vaguely like something that would be no skin off my back, so I'd be quite happy to help with this.

Re: Rust in QEMU Roadmap

#16

Post by rcxdude »

JoshTriplett wrote: post #7
greatgib wrote: post #5

[flagged]

By "the Rust community" here, you mean the author of the mail, one of the biggest long-standing developers of QEMU since before Rust was a thing? You're complaining that the developers of QEMU themselves are interested in adopting Rust because they think it'll work well for them?

This kind of thing reminds me of the backlash against systemd, where detractors felt like it was being imposed on the distributions that were for the most part adopting it because they liked what it offered.

Re: Rust in QEMU Roadmap

#17

Post by bonzini »

aapoalas wrote: post #15
bonzini wrote: post #11

Earlier quoted context omitted.

QEMU has several tracepoint providers, the main ones are (a slightly fancy version of) printf and USDT. There is a Python program that generates the C code for the chosen backend(s), so the thing to do would be to adjust the script to produce either an FFI bridge or the equivalent Rust code.

Can you link the script? This sounds vaguely like something that would be no skin off my back, so I'd be quite happy to help with this.

Yes it's https://github.com/qemu/qemu/tree/master/scripts/tracetool.

I also found https://github.com/cuviper/probe-rs/tree/master/src/platform which seems interesting.

Re: Rust in QEMU Roadmap

#18

Post by akira2501 »

JoshTriplett wrote: post #7
greatgib wrote: post #5

[flagged]

By "the Rust community" here, you mean the author of the mail, one of the biggest long-standing developers of QEMU since before Rust was a thing? You're complaining that the developers of QEMU themselves are interested in adopting Rust because they think it'll work well for them?

> one of the biggest long-standing developers

How many developers does the project have? What is your metric for "biggest?" Just total number of contributions?

> You're complaining that the developers of QEMU themselves

Yep. Do any of them work for any commercial companies? Or are we ignoring that to make an argument of appeals? If they all left would QEMU have zero developers?

> because they think it'll work well for them?

Looking at the set of challenges presented at the bottom of the email and their wiki I'm not sure this idea is well founded. There are more wacky compromises listed than there are good ideas.

If you're just going to push hacks upstream and maintain vendor forks downstream then why wouldn't you just start a new project and bring in whatever bits of C code you need until you can replace them.

I've yet to these efforts actually reduce baggage or show any hope of showing returns on investment inside of a decade of insane effort, which always seems to hamper any further feature or bugfix development, out of fear of interrupting other agonizing "works in progress."

Some of this think this is clearly goofy and can't help but comment on it.

Re: Rust in QEMU Roadmap

#19

Post by akira2501 »

rcxdude wrote: post #16
JoshTriplett wrote: post #7

Earlier quoted context omitted.

By "the Rust community" here, you mean the author of the mail, one of the biggest long-standing developers of QEMU since before Rust was a thing? You're complaining that the developers of QEMU themselves are interested in adopting Rust because they think it'll work well for them?

This kind of thing reminds me of the backlash against systemd, where detractors felt like it was being imposed on the distributions that were for the most part adopting it because they liked what it offered.

systemd has tried to alter the kernel in breaking ways for it's own ends plenty of times. it's easy enough to not use and plenty of distributions do so with some effort but it's not as if systemd has had zero consequences on the rest of the ecosystem.

Re: Rust in QEMU Roadmap

#20

Post by bonzini »

akira2501 wrote: post #18
JoshTriplett wrote: post #7

Earlier quoted context omitted.

By "the Rust community" here, you mean the author of the mail, one of the biggest long-standing developers of QEMU since before Rust was a thing? You're complaining that the developers of QEMU themselves are interested in adopting Rust because they think it'll work well for them?

> one of the biggest long-standing developers How many developers does the project have? What is your metric for "biggest?" Just total number of contributions? > You're complaining that the developers of QEMU themselves Yep. Do any of them work for any commercial companies? Or are we ignoring that to make an argument of appeals? If they all left would QEMU have zero developers? > because they think it'll work well fo…

> There are more wacky compromises listed than there are good ideas.

I am happy to learn about other's opinions and especially contrary opinions, otherwise I would not have made a public post. I am myself not 100% sure that the idea will be successful, it would be stupid to think it certainly will; but the good thing is that the existing C code will be unaffected (or improved; for example https://lore.kernel.org/qemu-devel/20241129180326.722436-1-p... was found while looking at the code to write the corresponding Rust bindings).

Sometimes you have to try crazy things. One perhaps controversial changes I headed in QEMU was to introduce the Meson build system. You may wonder what is wrong with me. I am happy to say that since then I have almost never had to ask a question about the build system, which was a very common occurrence before, and it has actually simplified the implementation of features such as custom device configuration, improved module loading, entitlement support for macOS, relocatable installs, autogenerated parsing of the configure command line, improvements to cross-compilation. While slightly reducing the number of lines of code compared to before. So I disagree that exploratory work is "a decade of insane effort".

So I am curious, what are the wacky compromises?

Post reply on HN