Re: [PATCH v18 00/18] KVM RISC-V Support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Driver Development]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux