From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45443) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QKtzX-0005gl-P6 for qemu-devel@nongnu.org; Fri, 13 May 2011 11:09:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QKtzW-0007FG-6D for qemu-devel@nongnu.org; Fri, 13 May 2011 11:09:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35041) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QKtzV-0007Ey-Ts for qemu-devel@nongnu.org; Fri, 13 May 2011 11:09:22 -0400 Date: Fri, 13 May 2011 12:09:16 -0300 From: Luiz Capitulino Message-ID: <20110513120916.6e4bde05@doriath> In-Reply-To: References: <1305212715-26767-1-git-send-email-armbru@redhat.com> <1305212715-26767-4-git-send-email-armbru@redhat.com> <20110512140143.1ffb7eeb@doriath> <20110512142205.52c60ed4@doriath> <20110512153635.3a421dbc@doriath> <20110513103939.6c7dfe76@doriath> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 3/6] block QMP: Drop query-block member "type" (type= in info block) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, hch@lst.de, qemu-devel@nongnu.org, kraxel@redhat.com On Fri, 13 May 2011 16:13:55 +0200 Markus Armbruster wrote: > Luiz Capitulino writes: > > > On Fri, 13 May 2011 10:26:38 +0200 > > Markus Armbruster wrote: > > > >> Luiz Capitulino writes: > >> > >> > On Thu, 12 May 2011 19:54:40 +0200 > >> > Markus Armbruster wrote: > >> > > >> >> Luiz Capitulino writes: > >> >> > >> >> > On Thu, 12 May 2011 19:12:56 +0200 > >> >> > Markus Armbruster wrote: > >> >> > > >> >> >> Luiz Capitulino writes: > [...] > >> >> >> > Also, we can't just drop it from QMP. We should first note it's deprecated. > >> >> >> > >> >> >> Would you accept a change to the more honest value "unknown" for the > >> >> >> deprecation period? > >> >> > > >> >> > We have to avoid breaking the protocol. Changing something that has always > >> >> > been reported as 'cdrom' to 'unknown' will likely cause as many as damages > >> >> > as dropping the command. > >> >> > >> >> I can cause damage only if somebody is using it. Which I doubt. > >> > > >> > Me too and I'd agree with this patch if I was 100% sure. But it's impossible > >> > to be sure, unless we do it by trial and error which is harmful. > >> > > >> >> Remember, the value is unreliable. It's a *lie*. We can stop lying in > >> >> two ways: shut up (drop member "type"), or tell the truth (change the > >> >> value to "unknown", which is a documented value of "type"). > >> > > >> > Can we set it to 'unknown' when if=none? > >> > >> Maybe. Makes query-block mix up host and guest information again. > > > > It's temporary, just to respect our deprecation policy and give us time > > to provide a viable alternative. > > > >> Purging guest information from block.c is the point of this series. > >> Therefore, query-block can't be done in block.c anymore. It needs to > >> move to blockdev.c, where the mixed-up-by-design DriveInfo is available. > >> It could move back when we finally clean up query-block. > >> > >> Even with such compatibility gymnastics, it could still break your > >> hypothetical client. > > > > Our deprecation policy is not hypothetical. There isn't case by case. Either > > we respect it or we don't. > > My point is: even your deprecation policy cannot protect your > hypothetical client. > > The only way to ensure not even the silliest hypothetical client breaks > is not to change anything. Which means we cannot fix query-block not to > lie about the type, period. Which means we have to deprecate > query-block wholesale to fix that bug. Why don't we force the known broken cases (like if=none) to 'unknown', note in the doc that the field is unreliable and specify that it can be dropped in 2 or 3 releases? > > Kevin, please apply patches 1+2+6. Feel free to drop 3-5. > > [...] >