Am 16.03.2022 um 13:40 hat Stefan Hajnoczi geschrieben: > On Wed, Mar 16, 2022 at 12:08:33AM +0100, Paolo Bonzini wrote: > > On 3/15/22 16:55, Daniel P. Berrangé wrote: > > > Expecting maintainers to enforce a subset during code review feels > > > like it would be a tedious burden, that will inevitably let stuff > > > through because humans are fallible, especially when presented > > > with uninspiring, tedious, repetitive tasks. > > > > > > Restricting ourselves to a subset is only viable if we have > > > an automated tool that can reliably enforce that subset. I'm not > > > sure that any such tool exists, and not convinced our time is > > > best served by trying to write & maintainer one either. > > > > We don't need to have a policy on which features are used. We need to have > > goals for what to use C++ for. I won't go into further details here, > > because I had already posted "When and how to use C++"[1] about an hour > > before your reply. > > > > > IOW, I fear one we allow C++ in any level, it won't be practical > > > to constrain it as much we desire. I fear us turning QEMU into > > > even more of a monster like other big C++ apps I see which take > > > all hours to compile while using all available RAM in Fedora RPM > > > build hosts. > > > > Sorry but this is FUD. There's plenty of C++ apps and libraries that do not > > "take hours to compile while using all available RAM". You're probably > > thinking of the Chromium/Firefox/Libreoffice triplet but those are an order > > of magnitude larger than QEMU. And in fact, QEMU is *already* a monster > > that takes longer to compile than most other packages, no matter the > > language they're written in. > > > > Most of KDE and everything that uses Qt is written in C++, and so is > > Inkscape in GTK+ land. LLVM and Clang are written in C++. Hotspot and V8 > > are written in C++. Kodi, MAME and DolphinEmu are written in C++. GCC and > > GDB have migrated to C++ and their compile times have not exploded. > > > > > My other question is whether adoption of C++ would complicate any > > > desire to make more use of Rust in QEMU ? I know Rust came out of > > > work by the Mozilla Firefox crew, and Firefox was C++, but I don't > > > have any idea how they integrated use of Rust with Firefox, so > > > whether there are any gotcha's for us or not ? > > > > Any Rust integration would go through C APIs. Using Rust in the block layer > > would certainly be much harder, though perhaps not impossible, if the block > > layer uses C++ coroutines. Rust supports something similar, but > > two-direction interoperability would be hard. > > I haven't looked at this in depth but there is a solution for Rust-C++ > interop: https://cxx.rs/
"Direct FFI of async functions is absolutely in scope for CXX (on C++20 and up) but is not implemented yet in the current release." With the current QEMU coroutines, calling Rust async fns from C is relatively easy, and calling C coroutine_fns from a Rust async fn is trivial when the Rust async fn is already called from a C coroutine (because qemu_coroutine_yield() just works, we still have a coroutine stack from the original C caller). I suppose calling Rust async fns from C++ could actually have the same implementation as with C when using Paolo's wrappers, but the other direction might be a bit harder - to be honest, I can't tell because I've never checked how C++ coroutines work internally. Could as well be that a Rust wrapper for them isn't that hard after all. Kevin
signature.asc
Description: PGP signature
