From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55465 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhWgF-00031E-K4 for qemu-devel@nongnu.org; Mon, 24 Jan 2011 19:22:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PhWgE-00011r-72 for qemu-devel@nongnu.org; Mon, 24 Jan 2011 19:22:43 -0500 Received: from e4.ny.us.ibm.com ([32.97.182.144]:37207) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PhWgE-00011k-4X for qemu-devel@nongnu.org; Mon, 24 Jan 2011 19:22:42 -0500 Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0P017Vo008557 for ; Mon, 24 Jan 2011 19:04:19 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 4C64872804B for ; Mon, 24 Jan 2011 19:22:30 -0500 (EST) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0P0MTd0477580 for ; Mon, 24 Jan 2011 19:22:29 -0500 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0P0MTOq027004 for ; Mon, 24 Jan 2011 17:22:29 -0700 Message-ID: <4D3E17C0.1080504@linux.vnet.ibm.com> Date: Mon, 24 Jan 2011 18:22:24 -0600 From: Michael Roth MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC][PATCH v6 08/23] virtagent: add va.getfile RPC References: <1295270117-24760-1-git-send-email-mdroth@linux.vnet.ibm.com> <1295270117-24760-9-git-send-email-mdroth@linux.vnet.ibm.com> <4D39B716.1010400@redhat.com> <20110121172026.GK12589@redhat.com> <4D39CF2C.1000407@linux.vnet.ibm.com> <20110124220809.GA4254@amd.home.annexia.org> <20110124222019.GA4602@amd.home.annexia.org> <4D3DFC81.4010807@linux.vnet.ibm.com> <20110124224808.GF25174@amd.home.annexia.org> <4D3E0DD5.8070408@linux.vnet.ibm.com> In-Reply-To: <4D3E0DD5.8070408@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, Jes Sorensen , marcel.mittelstaedt@de.ibm.com, qemu-devel@nongnu.org, "Richard W.M. Jones" , ryanh@us.ibm.com, markus_mueller@de.ibm.com, abeekhof@redhat.com On 01/24/2011 05:40 PM, Anthony Liguori wrote: > On 01/24/2011 04:48 PM, Richard W.M. Jones wrote: >> On Mon, Jan 24, 2011 at 04:26:09PM -0600, Anthony Liguori wrote: >>> On 01/24/2011 04:20 PM, Richard W.M. Jones wrote: >>>> On Mon, Jan 24, 2011 at 10:08:09PM +0000, Richard W.M. Jones wrote: >>>>> You might as well reuse the libguestfs API here because you get the >>>>> benefit of all the code that's been written, all the tools on top, and >>>>> a far more comprehensive API that would take you another 2 years to >>>>> implement. >>>> To put it in some perspective, libguestfs is just shy of 500K lines of >>>> code now, not including the tools built on top. 150 page manual just >>>> for the core API. >>> Yeah, but I think that's the reason that it might not be a good >>> candidate for this use-case. >>> >>> We need a *simple* interface that we can convince everyone to >>> install by default and run in their guests. It needs to be flexible >>> enough that we can do lots of fun things but simple enough that a >>> reasonable person can audit the code in a short period of time. >>> >>> It will never replace something as sophisticated as guestfs but >>> that's not it's point. It's point is to let you do simple things >>> like execute a command in the guest or peek at /proc/meminfo. You >>> don't need 500k LOCs for that. >> I don't really want to argue over this, since I think accessing live >> VMs like this is a really useful feature, and it complements >> libguestfs (image editing) very nicely. >> >> I'll just say that you might not think you need it to start off with >> (and we didn't either), but when you notice that "simple" >> open/read/write/close > > Oh I don't think there should be an open/read/write/close interface. I'm > quite happy with the current copyfile interface. Actually, copyfile is the proposed open/read/write/close interface. getfile is the current interface, and it seems to be a contentious one. I've discussed it quite a bit with Jes here and in the last couple RFCs. I think the current course is that we'll end up ditching viewfile/viewdmesg in favor of copyfile, and that we should do it now rather than later. The upshot is that "viewfile " is basically equivalent to: copyfile_open /dev/stdout -> fd_handle; copyfile_read fd ; copyfile_close fd_handle". Or we can output to a file and potentially introduce a monitor command that wraps these to provide simple oneliner like we have now, though there may be some reluctance there as well. But at least it'll be possible either way. > >> in fact has terrible performance so you need to >> specialize many operations, and then someone wants to create a >> filesystem, and someone else wants a FUSE interface, suddenly you'll >> be reimplementing large parts of libguestfs. > > Nope. If you want to do fancy things, use libguestfs :-) > > BTW, how dependent is guestfsd on the guest that libguestfs uses? I > wasn't even aware that it could be used outside of that context. > > Regards, > > Anthony Liguori > >> The daemon (guestfsd) is 36106 LoC. >> >> Rich. >> >