Re: [Qemu-devel] Re: [RFC][PATCH v6 08/23] virtagent: add va.getfile RPC

From: Anthony Liguori <aliguori@linux.vnet.ibm.com>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com,
	Jes Sorensen <Jes.Sorensen@redhat.com>,
	marcel.mittelstaedt@de.ibm.com, qemu-devel@nongnu.org,
	Michael Roth <mdroth@linux.vnet.ibm.com>,
	ryanh@us.ibm.com, markus_mueller@de.ibm.com, abeekhof@redhat.com
Subject: Re: [Qemu-devel] Re: [RFC][PATCH v6 08/23] virtagent: add va.getfile RPC
Date: Mon, 24 Jan 2011 17:40:05 -0600	[thread overview]
Message-ID: <4D3E0DD5.8070408@linux.vnet.ibm.com> (raw)
In-Reply-To: <20110124224808.GF25174@amd.home.annexia.org>

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.

>   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.
>
>    