From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: [Qemu-devel] KVM call agenda for Tuesday, July 3rd Date: Tue, 03 Jul 2012 14:33:22 +0200 Message-ID: <4FF2E692.7050900@redhat.com> References: <874npqwjqe.fsf@elfo.mitica> <4FF1DB7D.1000006@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: quintela@redhat.com, qemu-devel@nongnu.org, KVM devel mailing list , Corey Bryant To: Eric Blake Return-path: Received: from mx1.redhat.com ([209.132.183.28]:34117 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750960Ab2GCMd3 (ORCPT ); Tue, 3 Jul 2012 08:33:29 -0400 In-Reply-To: <4FF1DB7D.1000006@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Am 02.07.2012 19:33, schrieb Eric Blake: > On 07/02/2012 04:16 AM, Juan Quintela wrote: >> >> Hi >> >> Please send in any agenda items you are interested in covering. > > Can we discuss the future of 'getfd', the possibility of 'pass-fd', or > even the enhancement of all existing monitor commands to take an > optional 'nfds' JSON argument for atomic management of fd passing? > Which commands need to reopen a file with different access, and do we > bite the bullet to special case all of those commands to allow fd > passing or can we make qemu_open() coupled with high-level fd passing > generic enough to satisfy all of our reopen needs? Sure we can, at least if Corey will attend the call. Otherwise I guess it's better to keep the discussion on the mailing list. Kevin