|
| From: | Palmer Dabbelt |
| Subject: | Re: [Qemu-devel] [PULL] First RISC-V Patch Set for the 3.1 Soft Freeze |
| Date: | Thu, 18 Oct 2018 11:26:25 -0700 (PDT) |
On Thu, 18 Oct 2018 05:54:01 PDT (-0700), Michael Clark wrote:
Any patches intended for the RISC-V port should go through the maintainer tree. I have been pretty clear that I would like to run regression tests. I do not wish to pull surprises in via master. I also do not agree with this random patch approach. It's all well and good for inactive maintainers to pop up now, but we were not getting our patches reviewed. The riscv-qemu tree is actively managed and we rebase and test at release time. I don't like the idea of busted stuff getting into the tree with patch churn correcting it. In any case we disagree regards process. Please don't break any of the branches in the riscv-qemu repository. I have scripts to tag our stable branches there (we got positive feedback from Karsten on the "series"). You are adding risk to the process. Fine. You are in charge. Don't break stuff.
Sorry Michael, I thought we talked about this last week in on the call and decided that you were happy to let someone else take over the process of getting the current RISC-V patch queue upstream. While I agree there's a risk to submitting patches, right now we're in the position where there are known bugs in the upstream QEMU port. The real intent here is to provide a process by which we can get the RISC-V QEMU port flowing smoothly. You haven't submitted a PR since May, and as a result it's very hard for a community to develop around the RISC-V port -- distros have to go track down out-of-tree patches, releases have known bugs, developers don't know where to start, etc. I know it's easy to get overwhelmed (that happened to me with both binutils and Linux), and I thought we agreed that you'd be happy to have someone else help out with shepherding patches from the RISC-V patch queue into master. I know it's hard to get the ball rolling, but the longer we wait the harder it'll be.
I purposefully created a new "for-master" branch on the RISC-V QEMU github repo to avoid touching any of the branches you've been maintaining, and my intent was for all these patches to have come off of "for-upstream" (which IIUC is the RISC-V patch queue). If I screwed anything up then let me know.
Maybe we can talk about what we're going to do here this afternoon? I certainly don't want to step on your toes here, but I really would like to get patches to start flowing upstream.
Sorry for the confusion, everyone!
On Thu, Oct 18, 2018 at 1:01 PM Palmer Dabbelt <address@hidden> wrote:On Wed, 17 Oct 2018 16:32:10 PDT (-0700), address@hidden wrote: > On 10/17/18 4:54 PM, Palmer Dabbelt wrote: >> The following changes since commit 09558375a634e17cea6cfbfec883ac2376d2dc7f: >> >> Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20181016-1' into staging (2018-10-16 17:42:56 +0100) >> >> are available in the Git repository at: >> >> git://github.com/riscv/riscv-qemu.git tags/riscv-for-master-3.1-sf0 >> >> for you to fetch changes up to 7c28f4da20e5585dce7d575691dac5392b7c6f78: >> >> RISC-V: Don't add NULL bootargs to device-tree (2018-10-17 13:02:30 -0700) >> >> ---------------------------------------------------------------- >> First RISC-V Patch Set for the 3.1 Soft Freeze >> > >> ---------------------------------------------------------------- >> Michael Clark (5): >> RISC-V: Allow setting and clearing multiple irqs >> RISC-V: Move non-ops from op_helper to cpu_helper >> RISC-V: Update CSR and interrupt definitions >> RISC-V: Add missing free for plic_hart_config >> RISC-V: Don't add NULL bootargs to device-tree >> > > Isn't this just a subset of Alistair's pull request? > https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg02342.html Yes, but there's still on-going discussion about the PCIe patches so they're not really fully reviewed. I think part of the trouble here is that there wasn't someone submitting regular QEMU pull requests so there was always a rush to get things in. I've volunteered to wrangle the branches and submit weekly pull requests (just like I do for Linux), so now there won't be any more big cliffs. We've got a lot of patches to filter through because things have been backed up for a bit, so I thought it'd be best to just go with something simple for this first week. Assuming everything gets sorted out for the PCIe patches they'll just go up next week -- I'm super excited for them as well :) > which included: >> ---------------------------------------------------------------- >> Alistair Francis (5): >> hw/riscv/virt: Increase the number of interrupts >> hw/riscv/virt: Connect the gpex PCIe >> riscv: Enable VGA and PCIE_VGA >> hw/riscv/sifive_u: Connect the Xilinx PCIe >> hw/riscv/virt: Connect a VirtIO net PCIe device >> >> Michael Clark (5): >> RISC-V: Allow setting and clearing multiple irqs >> RISC-V: Move non-ops from op_helper to cpu_helper >> RISC-V: Update CSR and interrupt definitions >> RISC-V: Add missing free for plic_hart_config >> RISC-V: Don't add NULL bootargs to device-tree
| [Prev in Thread] | Current Thread | [Next in Thread] |