From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Date: Wed, 19 May 2021 15:29:24 +0200 Subject: [PATCH v18 00/18] KVM RISC-V Support In-Reply-To: References: <20210519033553.1110536-1-anup.patel@wdc.com> Message-ID: List-Id: To: kvm-riscv@lists.infradead.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On 19/05/21 14:23, Greg Kroah-Hartman wrote: >> - the code could be removed if there's no progress on either changing the >> RISC-V acceptance policy or ratifying the spec > > I really do not understand the issue here, why can this just not be > merged normally? Because the RISC-V people only want to merge code for "frozen" or "ratified" processor extensions, and the RISC-V foundation is dragging their feet in ratifying the hypervisor extension. It's totally a self-inflicted pain on part of the RISC-V maintainers; see Documentation/riscv/patch-acceptance.rst: We'll only accept patches for new modules or extensions if the specifications for those modules or extensions are listed as being "Frozen" or "Ratified" by the RISC-V Foundation. (Developers may, of course, maintain their own Linux kernel trees that contain code for any draft extensions that they wish.) (Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/riscv/patch-acceptance.rst) > All staging drivers need a TODO list that shows what needs to be done in > order to get it out of staging. All I can tell so far is that the riscv > maintainers do not want to take this for "unknown reasons" so let's dump > it over here for now where we don't have to see it. > > And that's not good for developers or users, so perhaps the riscv rules > are not very good? I agree wholeheartedly. I have heard contrasting opinions on conflict of interest where the employers of the maintainers benefit from slowing down the integration of code in Linus's tree. I find these allegations believable, but even if that weren't the case, the policy is (to put it kindly) showing its limits. >> Of course there should have been a TODO file explaining the situation. But >> if you think this is not the right place, I totally understand; if my >> opinion had any weight in this, I would just place it in arch/riscv/kvm. >> >> The RISC-V acceptance policy as is just doesn't work, and the fact that >> people are trying to work around it is proving it. There are many ways to >> improve it: > > What is this magical acceptance policy that is preventing working code > from being merged? And why is it suddenly the rest of the kernel > developer's problems because of this? It is my problem because I am trying to help Anup merging some perfectly good KVM code; when a new KVM port comes up, I coordinate merging the first arch/*/kvm bits with the arch/ maintainers and from that point on that directory becomes "mine" (or my submaintainers'). Paolo