On Wed, Jun 24, 2026 at 5:18 AM Pierrick Bouvier <[email protected]> wrote: > > On 6/23/2026 12:01 PM, Daniel Henrique Barboza wrote: > > > > > > On 6/23/2026 1:10 PM, Pierrick Bouvier wrote: > >> On 6/23/2026 4:38 AM, Daniel Henrique Barboza wrote: > >>> > >>> > >>> On 6/23/2026 6:58 AM, Peter Maydell wrote: > >>>> On Tue, 23 Jun 2026 at 10:49, Daniel Henrique Barboza > >>>> <[email protected]> wrote: > >>>>> > >>>>> > >>>>> > >>>>> On 6/22/2026 6:34 PM, Pierrick Bouvier wrote: > >>>>>> On 6/22/2026 2:23 PM, Philippe Mathieu-Daudé wrote: > >>>>>>> On 22/6/26 22:52, Pierrick Bouvier wrote: > >>>>>>>> On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote: > >>>>>>>>> Hello, > >>>>>>>>> > >>>>>>>>> This series looks scary but it's mostly trivial and mechanical > >>>>>>>>> work. > >>>>>>>>> > >>>>>>>>> It is yet another attempt at fixing --disable-tcg. We have a > >>>>>>>>> recent > >>>>>>>>> work sent to the ML [1] and we had Phil's attempt back in 2023 > >>>>>>>>> [2]. > >>>>>>>>> Phil's work didn't get merged and it's now too hard to rebase and > >>>>>>>>> revive, the most recent attempt got misled into the 'what is > >>>>>>>>> common code > >>>>>>>>> between TCG and KVM' dungeon. > >>>>>>> > >>>>>>> > >>>>>>>> It seems like series does not apply on top of master, would that be > >>>>>>>> possible to rebase it? > >>>>>>> > >>>>>>> For some reason the RISC-V series are handled distinctly than the > >>>>>>> rest of QEMU, Alistair queues work on his repository and developers > >>>>>>> are custome to base their series on top of it (otherwise Alistair > >>>>>>> can not apply them on his tree and asks for reposts), see the > >>>>>>> riscv-to-apply.next branch on https://github.com/alistair23/qemu. > >>>>>> > >>>>>> Unfortunately, it makes it hard to run any kind of automated testing, > >>>>>> especially for series like this that target specific configs. > >>>>> > >>>>> Don't we have ways of saying in the commit message "these patches > >>>>> applies > >>>>> on top of these other patches" and then the tooling would deal with > >>>>> it? > >>>>> I remember patchew doing stuff like that with that "Based-on: > >>>>> <message-id>" > >>>>> tag. > >>>> > >>>> Yes, Based-on: is our convention for marking "this patchset needs some > >>>> other one to be applied first". But that should be the exception rather > >>>> than a common case -- if patchsets regularly need to be based on > >>>> something other than head-of-git, this is I think a sign that > >>>> maintainers are not sending out pull requests frequently enough. > >>>> > >>>> I would prefer it if QEMU didn't develop kernel-style "subsystems > >>>> have their own particular workflows" fragmentation -- I don't > >>>> think we're big enough or that sub-parts of QEMU are sufficiently > >>>> well separated for it to work out well. > >>> > >>> I agree that rebasing things on master is better than rebasing it on the > >>> maintainer's tree. And we could make a better job at informing > >>> developers that > >>> submitting a patch for qemu-riscv, vfio or any particular subtree, means > >>> that > >>> the patch should be based on a maintainer tree X. > >>> > >>> The thing is that sending patches on master only works if master is > >>> always up > >>> to date, and that's not feasible with our current style of merging PRs. > >>> This > >>> series we're commenting on is an example: it doesn't apply to master > >>> because > >>> there are pre-approved RISC-V patches in the maintainer's tree from 2 > >>> days ago > >>> (also my patches, I might add) that caused conflicts that I wasn't aware > >>> that > >>> would happen. This conflict would have to be dealt with at some point > >>> by myself > >>> or the maintainer, and it's not like 2 days is too much time without > >>> a PR. > >>> > >>> We can argue "this is an exception that doesn't happen that often, we > >>> should > >>> stick with using master as a base", and to a certain extend that's > >>> true. But > >>> then this sort of conflict happens again, then again, then again, it > >>> comes to > >>> a point where it's easier to tell developers to use the maintainer's > >>> tree instead > >>> of master. > >>> > >>> Maybe I'm downplaying the problem because I've been sending stuff based > >>> on the > >>> maintainer's tree since forever and got used to it. IMO, unless we > >>> decide to be > >>> like libvirt and create the "committer" role to allow trustworthy devs > >>> to push > >>> stuff to master after acks, making it more feasible to expect master to > >>> be up to > >>> date, I'm afraid we're closer to a kernel-style workflow. For better or > >>> worse. > >>> > >>> > >>> Thanks, > >>> Daniel > >>> > >>> > >>>> > >>>> thanks > >>>> -- PMM > >>> > >> > >> In this very specific case, where base patches are needed, maybe it > >> would be better to make the required commits appear in this series, and > >> mention in cover letter that patches 1-N are just coming from another > >> series and are already reviewed/approved. IMHO it doesn't hurt, and > >> reviewers are free to skip commits already reviewed. > > > > That's fair enough but I wonder if that won't scare people away with > > even bigger series :D in this case here I would need to either send all > > the queued patches, making the series go to 40+, or I would need to triage > > which patches from the queue creates a conflict with this work and send > > only those. > > > > Now, as for qemu-ci ... How farfetched it is to make it read a specific > > tag > > in the cover-letter, e.g. "branch-id", that can point to a gitlab/github > > repo with the patches, and use that code base instead of applying the > > patches to the master branch? Then for the next version of this work > > I could do > > > > "branch-id: https://gitlab.com/danielhb/qemu/-/tree/riscv_disabletcg_v2"; > > > > Based-on: is a QEMU specific tag, that is only understood by patchew, > and no other tool to my knowledge. > b4 has base_commit, which allows to give a specific base, but not a > specific repository. I'm not aware of any b4 tag that allows to mention > a base series. It makes sense, series are not branches, and stacking > them comes with a lot of problems. > > So it seems like email workflow is quite limited in this regard, and the > only way to deal with it properly is to wait for base patches to be > merged, or include them in the series. > > From another perspective, the same problem would exist if we would use a > forge like GitHub or GitLab. It's not possible to stack PR on top of > others, and only solution is to wait, or duplicate patches. IMHO, it's a > sane default, as it forces correct ordering instead of allowing chaotic > development. > > > and the tool would still work. If there's no "branch-id" then it assumes > > that the patches are to be applied on master. > > > > > > And yeah, in an ideal world the problem goes away if we just do more PRs > > and > > strive to keep 'master' updated. I'm just thinking out loud about possible > > alternatives until we reach that point.
When you sent v2 of this series it had been one week since the last RISC-V PR. Are we really aiming for more than one PR a week? > > > > > > Cheers, > > Daniel > > > >> > >> Or, a solution I'm not fond of but I ended up adopting most of the time, > >> just wait for required patches to be merged on master before posting the > >> series, and work on something else meanwhile. I do feel that a few people do that, just not Daniel :) Alistair > >> > >> Ideally, yes, it would be better if maintainers could send PR more > >> frequently to avoid creating those intermediate staging trees. The > >> faster we merge, the less conflicts we'll have. > >> > >> Regards, > >> Pierrick > > > >
