From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51412) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFMAt-0005I4-23 for qemu-devel@nongnu.org; Mon, 17 Feb 2014 06:15:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFMAm-00052n-0C for qemu-devel@nongnu.org; Mon, 17 Feb 2014 06:15:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:20147) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFMAl-00052f-Al for qemu-devel@nongnu.org; Mon, 17 Feb 2014 06:15:39 -0500 Date: Mon, 17 Feb 2014 12:15:37 +0100 From: Kevin Wolf Message-ID: <20140217111537.GG3502@dhcp-200-207.str.redhat.com> References: <1390558762-6941-1-git-send-email-kwolf@redhat.com> <20140217101456.GD3502@dhcp-200-207.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] target-i386: Fix I/O bitmap checks for in/out List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , Anthony Liguori , Richard Henderson Am 17.02.2014 um 11:47 hat Peter Maydell geschrieben: > On 17 February 2014 10:14, Kevin Wolf wrote: > > Am 24.01.2014 um 11:19 hat Kevin Wolf geschrieben: > >> Commit 1b90d56e changed the implementation of in/out imm to not assign > >> the accessed port number to cpu_T[0] as it appeared unnecessary. > >> However, currently gen_check_io() makes use of cpu_T[0] to implement the > >> I/O bitmap checks, so it's in fact still used and the change broke the > >> check, leading to #GP in legitimate cases (and probably also allowing > >> access to ports that shouldn't be allowed). > >> > >> This patch reintroduces the missing assignment for these cases. > >> > >> Signed-off-by: Kevin Wolf > >> Reviewed-by: Richard Henderson > > > > Ping? > > > > /me considers sending a one-patch pull request for an area he's > > absolutely not maintaining, but if this is the only way to get patches > > applied to qemu... > > I don't currently have a workflow for identifying and applying > patches which aren't in pull requests (apart from obvious > "fixes build breakage" patches, and even there it's depending > on my happening to notice them). In this case I'd expect rth > to put together a pull request, I guess. The problem is the "I guess" part, especially if Richard guesses otherwise. target-i386 happens to be an officially unmaintained area. This is the get_maintainer.pl output: qemu-devel@nongnu.org (odd fixer:X86) Richard Henderson (commit_signer:123/126=98%) Peter Maydell (commit_signer:51/126=40%) Paolo Bonzini (commit_signer:32/126=25%) Blue Swirl (commit_signer:13/126=10%) Richard, would you be willing to take up official maintainership to solve at least this uncertainty? > Suggestions for better workflows welcome; we have had issues > with patches falling through the gaps between maintained > subsystems for a long time. Yes, we have a lot of code that doesn't fall in any subsystem with a subtree maintainer. This is the really worrying part here. I'm pretty sure I would get this specific patch merged the one or the other way (after all, my pull requests are generally accepted), but if even I fail to get it in using the "normal" way, it probably also means that contributors outside of the core team have no chance at all getting any patches in. This is alarming and certainly can't be healthy. I think Anthony did try to apply such patches that don't belong to any submaintainer's area (even though often with considerable delays), but I'm not sure how much time it cost him and how he managed to filter them. Anthony, any hints? Kevin