From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEh5N-0007sC-JB for qemu-devel@nongnu.org; Thu, 20 Sep 2012 09:46:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEh5J-0001a4-85 for qemu-devel@nongnu.org; Thu, 20 Sep 2012 09:46:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38545) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEh5I-0001ZI-U7 for qemu-devel@nongnu.org; Thu, 20 Sep 2012 09:46:29 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8KDkR01028142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 20 Sep 2012 09:46:28 -0400 Date: Thu, 20 Sep 2012 10:47:18 -0300 From: Luiz Capitulino Message-ID: <20120920104718.018c16b5@doriath.home> In-Reply-To: <505ACF52.7090108@redhat.com> References: <1348065078-5139-1-git-send-email-pbonzini@redhat.com> <1348065078-5139-2-git-send-email-pbonzini@redhat.com> <20120919174229.28597314@doriath.home> <505ACF52.7090108@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 01/12] monitor: use monitor_handle_fd_param for non-Error-friendly users of named fds List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org On Thu, 20 Sep 2012 10:09:54 +0200 Paolo Bonzini wrote: > Il 19/09/2012 22:42, Luiz Capitulino ha scritto: > > On Wed, 19 Sep 2012 16:31:04 +0200 > > Paolo Bonzini wrote: > > > >> monitor_handle_fd_param and monitor_get_fd are mostly the same, except > >> that monitor_handle_fd_param does error reporting wrong. Use it in all > >> other places that do it wrong, instead of reinventing it. > > > > Hmm, why do we want to do this? > > > > As far as I understand it the main difference between the two functions > > is that if fdname is a number (for a weak definition of number), > > monitor_handle_fd_param() assumes that the fd already exists in qemu > > (eg. it was passed by the parent process). > > Oops, right, I remembered it was the other way round (i.e. first search > for a named file descriptor, and fall back to a numeric one). That's a lot better, IMO. > > Another side effect is that you add the possibility of functions > > changing from monitor_get_fd() to monitor_handle_fd_param() to also take > > fds passed by the parent process. Might be positive, but I wonder if that's > > useful for the commands you're changing. > > Making behavior more uniform may be a useful thing on its own. We might > even consider moving it to monitor_get_fd (with the above tweak for > compatibility). Yes, although I can think of another issue: suppose an mngt app passes an fd with fdname=9, but the fd doesn't reach qemu for some reason. Then the mngt app executes a qmp command with fdname=9 and fd 9 turns out to exist in qemu... Actually, a mngt app could do this even w/o passing an fd to qemu. Not sure how relevant this issue is though, as this can happen today with qmp commands using monitor_handle_fd_param(). > BTW, pci-assign.c is open-coding > monitor_handle_fd_param (including the numeric file descriptor behavior) > and we can remove the surrounding if. Yes, that's fine.