Peter Maydell <[email protected]> writes: > On Thu, 29 Jan 2026 at 21:44, Philippe Mathieu-Daudé <[email protected]> > wrote: >> >> Hi Peter, >> >> (+Paolo / Eric) >> >> On 29/1/26 21:31, Peter Maydell wrote: >> > >> > What are we trying to achieve here, and why does it benefit >> > us as an upstream project ? >> > >> > cf previous email thread from 2024 >> > https://lore.kernel.org/qemu-devel/[email protected]/ >> > about "drip-feeding" of this kind of patch with no clear take >> > on what the end state is or how much churn it's going to induce. >> >> I clearly know QEMU is not a C++ project. Now I don't see why we should >> be reluctant to have headers being usable by a C++ compiler, as long as >> it doesn't make our project worst to maintain. > > Every bit of code that is written by some downstream in C++ is > some thing that will essentially then never be upstreamed without > a big rewrite. So making it easier for downstreams to use C++ > reduces our chances of seeing them contribute what they do back to us. > > It's also extra work for us (for instance in this thread you > proposed adding a CI job, which is more CI minutes cost to > the project, more work for maintainers when something that > builds fine locally falls over in the CI, and so on). > > Each individual fix might be trivial, but they add up. > So it matters whether this one is "this is the only thing > we tripped over since 2024" or "we just rebased to a new > QEMU version and are going to be submitting dozens of these > over the next few weeks". > >> See for example non-invasive commit 7246c4cc470 ("exec: don't use void* >> in pointer arithmetic in headers"): > >> or commit 17c7df806b3 ("exec: avoid using C++ keywords in function >> parameters"): > > For the record, I wasn't really enthusiastic about those changes > either, for essentially the same reasons.
+1 [...]
