qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [RFC][PATCH v6 08/23] virtagent: add va.getfile RPC
Date: Mon, 24 Jan 2011 17:40:05 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Lightning/1.0b1 Thunderbird/3.0.10

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]