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

141–150 of 184 posts

Re: Rust in QEMU Roadmap

#141

Post by Neywiny »

ThePhysicist wrote: post #25
masklinn wrote: post #22

Earlier quoted context omitted.

> I'm not a rust user but if it lets me use classes and templates, I'll switch over Yer not switching any time soon then. Rust does have methods but not classes (QOM’s inheritance is specifically called as an issue in TFA) and it uses Haskell-style generics rather than C++-style templates.

I mean it has polymorphism via v-tables and composition via traits, that's enough object-orientation for me. Inheritance is a core principle of OOP but in practice most C++ class hierarchies are relatively flat (there are exceptions like Qt, which I think uses inheritance in a good way), in practice most of that can be mimicked with embedding and composition well enough to work. Not sure if you want to call that obje…

You can do it with macros, the problem is A) documentation B) macro abuse

It's so much harder to debug things when function calls are secretly macros, and if I didn't have the vscode cpp language server for goto definition, I'd be completely lost. I'd wager that only 5% of the #defines aren't auto generated by occasionally recursive macros. Maybe hyperbole. Makes it really hard to figure out how existing code works.

Re: Rust in QEMU Roadmap

#142

Post by vlovich123 »

pm215 wrote: post #109
vlovich123 wrote: post #106

Earlier quoted context omitted.

These two statements to me seem contradictory: > QEMU has historically not made particularly timely security fixes either on mainline or on branches > It's much easier for us to stick to making source releases, and delegate the job of providing binaries to our downstreams Am I correct that this is essentially saying "we're going to do a snapshot of the software periodically but end users are responsible for applying…

Security patches are usually developed by upstream devs and get applied to mainline fairly promptly[1], but you don't want to run head-of-git in production. If you run a distro QEMU then the distro maintainers backport security fixes to whatever QEMU they're currently shipping and produce new packages. None of this is particularly QEMU specific. There's a whole infrastructure of security mailing lists and disclosure…

Sure, but then why does the mainline branch need to worry about supporting the rust that’s bundled with the last stable Debian release? By definition that’s not going into a distro (or the distro is building mainline with rusts latest release anyway).

Is it a precautionary concern that backporting patches gets more complicated if the vuln is in Rust code?

But then again Rust code isn’t even compiled by default so I guess I’m not sure why you’re bothering to support for old versions of the toolchain in mainline, at least this early in the development process. Certainly not a two year old toolchain.

Re: Rust in QEMU Roadmap

#143

Post by david-gpu »

o11c wrote: post #55
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).

> Related to this, the IsA trait allows typesafe compile-time checked casts. Unlike in C code, casting to a superclass can be written in such a way that the compiler will complain if the destination type is not a superclass, and with zero runtime cost. This is unfair to C. With a little work when defining all classes (or non-leaf classes if you're willing for a hairier implementation), you can do this there too. Ther…

As a recovering language lawyer, I need to point out that what you are describing is not portable behavior because it is writing to one member of a union and reading from a different member, if I understood you correctly.

Will it work on most tool chains? Yes. But when it doesn't, it is going to be fun.

Re: Rust in QEMU Roadmap

#144

Post by rascul »

Neywiny wrote: post #140
IshKebab wrote: post #125

Earlier quoted context omitted.

I don't think he literally means templates and classes. Rust has equivalents that do the things you want templates and classes for (generics and structs/traits respectively). I completely agree with his point about reimplementing C++ badly in C. GNOME does this too in their libraries. He will be much happier with Rust.

Hmmm I think I actually really want classes. Something that combines data and methods together without more function pointers. Template vs generic I don't care about

Rust structs are in some ways similar to C++ classes. You can combine data and methods together with them without worrying about things like function pointers.

Re: Rust in QEMU Roadmap

#145

Post by rascul »

melon_tusk wrote: post #98
kouteiheika wrote: post #71

Earlier quoted context omitted.

> What are the other advantages exactly besides tool chain? It's a very productive language once you're experienced. I'm one of those people who (initially) didn't care about memory safety at all and just wanted a more productive C++, and for me it delivers on that perfectly. Nowadays I even use Rust for scripting , because with the right libraries it's just as productive for me as Ruby and Python can be while being…

"as productive as Ruby or Python" So you basically never have to worry about lifetimes or memory management or the borrow checker? Because that would be a prerequisite for it to be as productive as Python. I'd love to see a seasoned Python developer and a seasoned Rust developer comparing the time they spend to solve e.g. Advent of Code. I bet the Python dev would solve it at least ten times faster (developer time, n…

> So you basically never have to worry about lifetimes or memory management or the borrow checker? Because that would be a prerequisite for it to be as productive as Python.

To be more productive than Python? I almost never have to worry about lifetimes or the borrow checker. And even when I do, I'm still more productive.

Re: Rust in QEMU Roadmap

#146

Post by kstrauser »

jefbyokyie wrote: post #123
Neywiny wrote: post #21

I've said this before on here and I'll say it again. The QEMU code base is a nightmare. The amount of fake C++ is mind numbing. Every time I come across a variable or strict declaration or method with the word "class" in it, I'm reminded of how much easier the whole thing would've been with C++. You can't even compile C++ into QEMU because of how the headers use keywords. That's not even touching their macro abuse te…

C++23 is a godawful mess; especially the functional paradigms (which look beautiful in e.g. OCaml) that got shoehorned kicking and screaming into the morass that C++ had already been. If you read function specs in the OCaml docs, they're understandable and the syntax is clean; the same concepts bolted onto C++ look like line noise, both in actual syntax and the (allegedy) English-language description on en.cppreferen…

I cant believe I just read that entire izzys.case post. Wow. I couldn’t possibly assess it all for accuracy, but if that’s reasonably correct, just wow.

Re: Rust in QEMU Roadmap

#147

Post by bonzini »

david-gpu wrote: post #143
o11c wrote: post #55

Earlier quoted context omitted.

> Related to this, the IsA trait allows typesafe compile-time checked casts. Unlike in C code, casting to a superclass can be written in such a way that the compiler will complain if the destination type is not a superclass, and with zero runtime cost. This is unfair to C. With a little work when defining all classes (or non-leaf classes if you're willing for a hairier implementation), you can do this there too. Ther…

As a recovering language lawyer, I need to point out that what you are describing is not portable behavior because it is writing to one member of a union and reading from a different member, if I understood you correctly. Will it work on most tool chains? Yes. But when it doesn't, it is going to be fun .

No, you only need to assert that the field with that name exists.

Re: Rust in QEMU Roadmap

#148

Post by bonzini »

o11c wrote: post #108
bonzini wrote: post #61

Earlier quoted context omitted.

"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should." :D Though I admit that Rust also has to include the full list of base classes ( https://github.com/rust-lang/rfcs/pull/1268 would fix it).

The main reason the C version must hard-code is because C macros can't be recursive. What's Rust's excuse? (that said, the C approach is also nice for manually accessing fields of distant base classes)

In Rust's case it is that when you say "you have IsA for all types that implement IsA" you are actually saying "you have IsA for all types, but only if they implement IsA".

When you later say "you have IsA for all types, but only if they implement IsA" the two conditions conflict.

It might be possible to avoid this issue with a different implementation but this is the simplest one that works and QEMU's hierarchy is generally shallow. If a better implementation came along, it would be a matter of search and repeat.

Re: Rust in QEMU Roadmap

#149

Post by bonzini »

vlovich123 wrote: post #142
pm215 wrote: post #109

Earlier quoted context omitted.

Security patches are usually developed by upstream devs and get applied to mainline fairly promptly[1], but you don't want to run head-of-git in production. If you run a distro QEMU then the distro maintainers backport security fixes to whatever QEMU they're currently shipping and produce new packages. None of this is particularly QEMU specific. There's a whole infrastructure of security mailing lists and disclosure…

Sure, but then why does the mainline branch need to worry about supporting the rust that’s bundled with the last stable Debian release? By definition that’s not going into a distro (or the distro is building mainline with rusts latest release anyway). Is it a precautionary concern that backporting patches gets more complicated if the vuln is in Rust code? But then again Rust code isn’t even compiled by default so I g…

We already make an exception in that we don't support Debian bullseye (which is supported by the rest of QEMU until the April 2025 release), but not supporting Debian stable at all seemed too much.

That said we will probably switch to Debian rustc-web soon, and bump the lower limit to 1.75 or so.

Re: Rust in QEMU Roadmap

#150

Post by uecker »

vlovich123 wrote: post #137
uecker wrote: post #131

Earlier quoted context omitted.

I find it funny and sad at the same time that an installer for a "safe" programming language teaches people to download a shell script from a website and run it. What a farce.

With cert pinning, CT, and other advancements in transport security, I don't see a huge fundamental difference between this and adding a random apt repository & doing an apt install.

You should also not add random apt repositories from the internet. But there is still a major different in terms of the implications for user education.
Post reply on HN