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
