qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/3] two new file wrappers


From: mdroth
Subject: Re: [Qemu-devel] [PATCH 1/3] two new file wrappers
Date: Wed, 27 Feb 2013 17:06:51 -0600
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Feb 27, 2013 at 03:56:27PM -0600, mdroth wrote:
> On Wed, Feb 27, 2013 at 08:46:19AM -0500, Stefan Berger wrote:
> > On 02/26/2013 09:19 PM, Anthony Liguori wrote:
> > >address@hidden writes:
> > >
> > >I think we've moved away from using qemu-file for anything other than
> > >migration.
> > 
> > Our goal was to use the abstraction of a QEMUFile for writing into
> > memory buffers and later on to also provide a wrapper for writing
> > into block devices. This was all to be used for the NVRAM
> > implementation necessary for storing TPM persistent state.
> 
> One approach is to just keep all of this inside BER*Visitor, and do the
> distinction between memory/file via, for example,
> ber_output_visitor_new_file()/ber_output_visitor_new[_buffer]()
> 
> Would be kinda cool to move that into a {BE,LE}{File,Buffer}Visitor
> so you could use the visitor interfaces to handle the endian-conversions
> automagically, and then use that in BER*Visitor internally, but I'm not
> not sure how well that would work in practice.
> 
> Although, I did try to do something like that in the past to use it as a shim
> between the qemu_{put|get}* interfaces and QEMUFile in a misguided attempt to
> introduce a BER protocol for migration, but something similar might still
> be useful in your case:
> 
> http://lists.gnu.org/archive/html/qemu-devel/2011-09/msg02466.html
> 
> There's currently no visitor interface for arbitrary-length byte buffers
> though. The aforementioned patches relied on users creating their
> own loops around visit_type_int*() and friends. There's a patch floating
> around to add them but I don't see a need for it until we have a need to
> add support for specifying arrays in schema-defined QAPI types.

... okay, now i see the need :) see my response in patch 2.

> 
> Just another approach to consider though, I wouldn't see a problem with all
> this being done inside BER*Visitor for now.
> 
> > 
> >    Stefan
> > 
> > 



reply via email to

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