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 15:56:27 -0600
User-agent: Mutt/1.5.21 (2010-09-15)

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.

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]