From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54516) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXtwh-0002aN-Fd for qemu-devel@nongnu.org; Thu, 02 May 2013 09:53:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UXtwf-0001px-UA for qemu-devel@nongnu.org; Thu, 02 May 2013 09:53:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20202) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXtwf-0001pt-LF for qemu-devel@nongnu.org; Thu, 02 May 2013 09:53:13 -0400 Date: Thu, 2 May 2013 09:53:11 -0400 From: Luiz Capitulino Message-ID: <20130502095311.00192c06@redhat.com> In-Reply-To: <878v3x4hy9.fsf@codemonkey.ws> References: <1367005387-330-1-git-send-email-aliguori@us.ibm.com> <1367005387-330-4-git-send-email-aliguori@us.ibm.com> <20130502084926.GA30664@dhcp-200-207.str.redhat.com> <878v3x4hy9.fsf@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/3] gtk: add devices menu to allow changing removable block devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , qemu-devel@nongnu.org, Markus Armbruster On Thu, 02 May 2013 08:41:50 -0500 Anthony Liguori wrote: > >> + > >> + if (strcmp(type, "ide-cd") == 0) { > >> + disk_type = DT_CDROM; > >> + } else if (strcmp(type, "isa-fdc") == 0) { > >> + disk_type = DT_FLOPPY; > >> + } else { > >> + disk_type = DT_NORMAL; > >> + } > > > > Same thing here, comparing against strings is a hack. Devices should > > probably have a property that says what kind of device they are. > > Ack, this is nasty. I would like to eliminate this. There is a type > field in BlockInfo but: > > # @type: This field is returned only for compatibility reasons, it should > # not be used (always returns 'unknown') > > I vaguely remember this happening but I don't remember the specific > reason why. I would definitely prefer that we filled out type > correctly. > > I think Markus was involved in this. Markus or Luiz, do you remember > the story here? IIRC, we had a type field which was a string and Markus eliminated it because it was unreliable. I was afraid that dropping fields from a QMP output would be incompatible, so Markus maintained the field but it's always set to 'unknown'. It seems totally fine to me to have a new field with the device type as an enum, but of course it has to be reliable. PS: For more information about the reliableness of this field please contact Markus :)