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:
> > >jsch...@linux.vnet.ibm.com 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
> >
> >
