* Paolo Bonzini (pbonz...@redhat.com) 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.
While I think it does take longer to compile, the bigger problem for the CI setup is the amount of RAM-per-compile-process; it's not so much the fact that those applications are huge that's the problem, it's that a make -j ($threads) can run out of RAM. Dave > > 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. > > For everything else, not much. Even if using C++, the fact that QEMU's APIs > are primarily C would not change. Changing "timer_mod_ns(timer, ns)" to > "timer.modify_ns(ns)" is not on the table. > > But really, first of all the question should be who is doing work on > integrating Rust with QEMU. I typically hear about this topic exactly once > a year at KVM Forum, and then nothing. We have seen Marc-André's QAPI > integration experiment, but it's not clear to me what the path would be from > there to wider use in QEMU. > > In particular, after ~3 years of talking about it, it is not even clear: > > - what subsystems would benefit the most from the adoption of Rust, and > whether that would be feasible without a rewrite which will simply never > happen > > - what the plans would be for coexistence of Rust and C code within a > subsystem > > - whether maintainers would be on board with adopting a completely different > language, and who in the community has enough Rust experience to shepherd us > through the learning experience > > The first two questions have answers in the other message if s/Rust/C++/, > and as to the last I think we're already further in the discussion. > > Thanks, > > Paolo > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
