From: Paolo Bonzini <pbonzini@redhat.com> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Anup Patel <anup@brainfault.org>, Anup Patel <anup.patel@wdc.com>, Palmer Dabbelt <palmer@dabbelt.com>, Palmer Dabbelt <palmerdabbelt@google.com>, Paul Walmsley <paul.walmsley@sifive.com>, Albert Ou <aou@eecs.berkeley.edu>, Jonathan Corbet <corbet@lwn.net>, Alexander Graf <graf@amazon.com>, Atish Patra <atish.patra@wdc.com>, Alistair Francis <Alistair.Francis@wdc.com>, Damien Le Moal <damien.lemoal@wdc.com>, KVM General <kvm@vger.kernel.org>, kvm-riscv@lists.infradead.org, linux-riscv <linux-riscv@lists.infradead.org>, linux-doc@vger.kernel.org, "linux-kernel@vger.kernel.org List" <linux-kernel@vger.kernel.org>, linux-staging@lists.linux.dev Subject: Re: [PATCH v18 00/18] KVM RISC-V Support Date: Wed, 19 May 2021 15:29:24 +0200 [thread overview] Message-ID: <daa30135-8757-8d33-a92e-8db4207168ff@redhat.com> (raw) In-Reply-To: <YKUDWgZVj82/KiKw@kroah.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Anup Patel <anup@brainfault.org>, Anup Patel <anup.patel@wdc.com>, Palmer Dabbelt <palmer@dabbelt.com>, Palmer Dabbelt <palmerdabbelt@google.com>, Paul Walmsley <paul.walmsley@sifive.com>, Albert Ou <aou@eecs.berkeley.edu>, Jonathan Corbet <corbet@lwn.net>, Alexander Graf <graf@amazon.com>, Atish Patra <atish.patra@wdc.com>, Alistair Francis <Alistair.Francis@wdc.com>, Damien Le Moal <damien.lemoal@wdc.com>, KVM General <kvm@vger.kernel.org>, kvm-riscv@lists.infradead.org, linux-riscv <linux-riscv@lists.infradead.org>, linux-doc@vger.kernel.org, "linux-kernel@vger.kernel.org List" <linux-kernel@vger.kernel.org>, linux-staging@lists.linux.dev Subject: Re: [PATCH v18 00/18] KVM RISC-V Support Date: Wed, 19 May 2021 15:29:24 +0200 [thread overview] Message-ID: <daa30135-8757-8d33-a92e-8db4207168ff@redhat.com> (raw) In-Reply-To: <YKUDWgZVj82/KiKw@kroah.com> 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2021-05-19 13:29 UTC|newest] Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-19 3:35 [PATCH v18 00/18] KVM RISC-V Support Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 3:35 ` [PATCH v18 01/18] RISC-V: Add hypervisor extension related CSR defines Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 3:35 ` [PATCH v18 02/18] RISC-V: Add initial skeletal KVM support Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 9:24 ` Dan Carpenter 2021-05-19 9:24 ` Dan Carpenter 2021-05-19 10:17 ` Dan Carpenter 2021-05-19 10:17 ` Dan Carpenter 2021-05-19 3:35 ` [PATCH v18 03/18] RISC-V: KVM: Implement VCPU create, init and destroy functions Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 3:35 ` [PATCH v18 04/18] RISC-V: KVM: Implement VCPU interrupts and requests handling Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 3:35 ` [PATCH v18 05/18] RISC-V: KVM: Implement KVM_GET_ONE_REG/KVM_SET_ONE_REG ioctls Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 3:35 ` [PATCH v18 06/18] RISC-V: KVM: Implement VCPU world-switch Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 3:35 ` [PATCH v18 07/18] RISC-V: KVM: Handle MMIO exits for VCPU Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 3:35 ` [PATCH v18 08/18] RISC-V: KVM: Handle WFI " Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 3:35 ` [PATCH v18 09/18] RISC-V: KVM: Implement VMID allocator Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 3:35 ` [PATCH v18 10/18] RISC-V: KVM: Implement stage2 page table programming Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 3:35 ` [PATCH v18 11/18] RISC-V: KVM: Implement MMU notifiers Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 10:09 ` Dan Carpenter 2021-05-19 10:09 ` Dan Carpenter 2021-05-19 3:35 ` [PATCH v18 12/18] RISC-V: KVM: Add timer functionality Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 3:35 ` [PATCH v18 13/18] RISC-V: KVM: FP lazy save/restore Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 3:35 ` [PATCH v18 14/18] RISC-V: KVM: Implement ONE REG interface for FP registers Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 10:11 ` Dan Carpenter 2021-05-19 10:11 ` Dan Carpenter 2021-05-20 6:09 ` Dan Carpenter 2021-05-20 6:09 ` Dan Carpenter 2021-05-19 3:35 ` [PATCH v18 15/18] RISC-V: KVM: Add SBI v0.1 support Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 3:35 ` [PATCH v18 16/18] RISC-V: KVM: Document RISC-V specific parts of KVM API Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 3:35 ` [PATCH v18 17/18] RISC-V: KVM: Move sources to drivers/staging directory Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 3:35 ` [PATCH v18 18/18] RISC-V: KVM: Add MAINTAINERS entry Anup Patel 2021-05-19 3:35 ` Anup Patel 2021-05-19 4:58 ` [PATCH v18 00/18] KVM RISC-V Support Greg Kroah-Hartman 2021-05-19 4:58 ` Greg Kroah-Hartman 2021-05-19 5:10 ` Anup Patel 2021-05-19 5:10 ` Anup Patel 2021-05-19 5:10 ` Anup Patel 2021-05-19 5:21 ` Greg Kroah-Hartman 2021-05-19 5:21 ` Greg Kroah-Hartman 2021-05-19 10:47 ` Greg Kroah-Hartman 2021-05-19 10:47 ` Greg Kroah-Hartman 2021-05-19 11:18 ` Paolo Bonzini 2021-05-19 11:18 ` Paolo Bonzini 2021-05-19 12:23 ` Greg Kroah-Hartman 2021-05-19 12:23 ` Greg Kroah-Hartman 2021-05-19 13:29 ` Paolo Bonzini [this message] 2021-05-19 13:29 ` Paolo Bonzini 2021-05-19 13:58 ` Greg Kroah-Hartman 2021-05-19 13:58 ` Greg Kroah-Hartman 2021-05-19 15:08 ` Dan Carpenter 2021-05-19 15:08 ` Dan Carpenter 2021-05-19 15:26 ` Paolo Bonzini 2021-05-19 15:26 ` Paolo Bonzini 2021-05-21 17:13 ` Palmer Dabbelt 2021-05-21 17:13 ` Palmer Dabbelt 2021-05-21 17:21 ` Paolo Bonzini 2021-05-21 17:21 ` Paolo Bonzini 2021-05-21 17:47 ` Greg KH 2021-05-21 17:47 ` Greg KH 2021-05-21 18:08 ` Palmer Dabbelt 2021-05-21 18:08 ` Palmer Dabbelt 2021-05-21 18:25 ` Greg KH 2021-05-21 18:25 ` Greg KH 2021-05-21 20:25 ` Paolo Bonzini 2021-05-21 20:25 ` Paolo Bonzini 2021-05-24 7:09 ` Guo Ren 2021-05-24 7:09 ` Guo Ren 2021-05-24 7:09 ` Guo Ren 2021-05-24 22:57 ` Palmer Dabbelt 2021-05-24 22:57 ` Palmer Dabbelt 2021-05-24 23:08 ` Damien Le Moal 2021-05-24 23:08 ` Damien Le Moal 2021-05-25 7:37 ` Greg KH 2021-05-25 7:37 ` Greg KH 2021-05-25 8:01 ` Damien Le Moal 2021-05-25 8:01 ` Damien Le Moal 2021-05-25 8:11 ` Greg KH 2021-05-25 8:11 ` Greg KH 2021-05-25 8:24 ` Paolo Bonzini 2021-05-25 8:24 ` Paolo Bonzini
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=daa30135-8757-8d33-a92e-8db4207168ff@redhat.com \ --to=pbonzini@redhat.com \ --cc=Alistair.Francis@wdc.com \ --cc=anup.patel@wdc.com \ --cc=anup@brainfault.org \ --cc=aou@eecs.berkeley.edu \ --cc=atish.patra@wdc.com \ --cc=corbet@lwn.net \ --cc=damien.lemoal@wdc.com \ --cc=graf@amazon.com \ --cc=gregkh@linuxfoundation.org \ --cc=kvm-riscv@lists.infradead.org \ --cc=kvm@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=linux-staging@lists.linux.dev \ --cc=palmer@dabbelt.com \ --cc=palmerdabbelt@google.com \ --cc=paul.walmsley@sifive.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.