From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QKakd-0007y4-1O for qemu-devel@nongnu.org; Thu, 12 May 2011 14:36:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QKakb-0001qo-Vc for qemu-devel@nongnu.org; Thu, 12 May 2011 14:36:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8138) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QKakb-0001qf-Nz for qemu-devel@nongnu.org; Thu, 12 May 2011 14:36:41 -0400 Date: Thu, 12 May 2011 15:36:35 -0300 From: Luiz Capitulino Message-ID: <20110512153635.3a421dbc@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> 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 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: > >> > >> > On Thu, 12 May 2011 17:05:12 +0200 > >> > Markus Armbruster wrote: > >> > > >> >> Its value is unreliable: a block device used as floppy has type > >> >> "floppy" if created with if=floppy, but type "hd" if created with > >> >> if=none. > >> >> > >> >> That's because with if=none, the type is at best a declaration of > >> >> intent: the drive can be connected to any guest device. Its type is > >> >> really the guest device's business. Reporting it here is wrong. > >> > > >> > It reports how the guest is using the device, right? I'd say that's what > >> > users/clients are interested in knowing. > >> > >> The value is *unreliable*. It may or may not match how the guest is > >> using the device. I doubt users are interested in unreliable > >> information. > > > > Can't it be fixed? And how are users/clients supposed to find out how > > the guest is using its block devices? > > To find out more about the guest's devices, examine the guest's devices: > info qtree. Which is not converted to QMP yet. > You don't expect to find the guest serial devices in in "info chardev", > either. query-block's type member is a mistake, because it mixes up > guest device info with the host device info. Dropping it is a bug fix. I understand why you're dropping it, what I don't want to do is to break working clients. For example, there might be clients out there using it in a way that it's expected to work (eg. if=floppy). Of course that I'm assuming that such a client exist. > The fact that its value is unreliable is merely icing on the cake. > > >> > 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? > > The best solution I can think of is noting in the documentation that the > > information is unreliable and explain what clients interested in knowing > > this info should do. > > I'd be much more willing to jump through compatibility hoops if there > was *one* known user of this particular detail of QMP. Ideally, yes, but it's the type of thing we'll never know. > But if you insist on us continuing to lie, I'll find a way to continue > to lie. I'm resisting it, because I think it's a disservice to our > users. I also want to do the best for our users and I don't want to ignore the bug, but we don't know whether there are clients using the field. If we drop it and a client does use it, then we'll have failed in doing the best.