Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: > On 09/05/2017 04:17, Linus Torvalds wrote: >> I do tend to want to be *notified* about the conflicts, though. >> >> That's not because conflicts are bad per se, or because I'd find them >> hard to resolve (most are trivial). It's mostly because I want to know >> that both parties knew about the conflict and it was seen in -next, >> which just makes me feel a lot better about the it. >> >> Why? Exactly the same way I don't want submaintainers to silently fix >> up conflicts for me, because I want to be aware of where conflicts >> happened, I also want to know in turn that the submaintainers knew >> about it too. >> >> So to me, it's largely about *awareness*, not about "conflicts are >> hard to handle". I want to be aware of the conflicts, but I also want >> the people who caused them to be aware of them, and realize that >> "oops, we're stepping on each others toes". > > Good, that was my understanding - and I wanted to single out this > conflict because > > 1) I wasn't even sure if Paul was aware of it, since the conflict > surprised me when doing my own trial merge. I'd like to be aware of > arch vs. KVM conflicts, just like Linus, so that I can relay the > information to him precisely; Sure. In this case I think the conflict might have appeared after Paul sent the original pull request to you, because it took a while before you merged it. There was also the issue with needing to add the include of debugfs.h which was more subtle and I think distracted us from the simple conflict in the asm. > 2) I'm not sure about why PPC/KVM conflicts keep on happening. KVM on > PPC seems to be more tightly integrated with non-KVM code than other > architectures. _But it's also the other way round_ which seems less > healthy to me. I'm not sure if that is really necessary, but if not, > please refactor things so that we don't step on each other's toes > unnecessarily. Perhaps real mode handlers should be in > arch/powerpc/kernel/ and only arch/powerpc/kvm/, so that the latter only > cares about virtualization? Maybe the whole napping and CPU thread > management should be done outside arch/powerpc/kvm/? Not sure if that > makes any sense, but to my eyes there are definitely too many KVM parts > in hardware enablement patches (and BTW it's just crazy that PPC has > about 4k lines of assembly). I can't really say if it's more tightly integrated, I haven't looked that closely at other arches. What has happened is we've added support to the arch code and KVM for a new CPU version, which is not entirely backward compatible at the hypervisor level, support for an entirely new MMU which has implications for KVM, and for a new interrupt controller architecture. There've been some conflicts in the process, but I don't think we've done too badly. I suspect if x86 added support for a hash table MMU there might be some conflicts with KVM in the process ;) > Maybe PPC *is* the special snowflake where interaction should be > primarily with arch maintainers rather than myself. Then let's just > have topic branches for the occasional API patch (new KVM_CAP_* > constants would be the gist of it) and otherwise let Michael merge > KVM/PPC patches. In hindsight for the last couple of merge windows that probably would have worked better. But it's a bit late now :) I do wonder if at some point the relationship between the arch trees and KVM should flip. Something similar happened with perf, the hardware specific parts used to be merged through the perf tree, but now they go via arch maintainers. I'm not saying KVM is ready for that, but it might be one day. > But in any case, to my eyes there _is_ a pattern, and a problem. It > doesn't matter that the canary is a cherry-pick conflict that Linus > could solve blinded and with one hand tied behind his back. I don't think that there's really a "problem". It's not that Paul and I are oblivious to each other and "stepping on each other's toes", it's just we're working on areas of the code that are interdependent and sometimes there are conflicts. We could avoid all conflicts by forcing Paul to merge all his arch code one release before he merges the KVM code that needs it, but that would be silly IMHO. cheers
