Re: [Qemu-devel] [PATCH V8 14/14] Allow to provide inital TPM state

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Sep 01, 2011 at 11:00:56PM -0400, Stefan Berger wrote:
> >Do we really have to hand-craft file reading?
> >How large is TPMPROP_TPM_MAX_NV_SPACE?
> >If not too large, we can just allocate that
> >and do a single fread call?
> Yes, I could do that, too.
> >Or, we rely on glib now - can we use
> >g_io_channel_read_to_end () or something like that?
> >
> >
> GIOStatus   g_io_channel_read_to_end        (GIOChannel *channel,
>                                              gchar **str_return,
>                                              gsize *length,
>                                              GError **error);
> 
> I'd rather not use it. Presumably it uses g_malloc() to internally
> allocate the str_return. However, the buffer we are allocating in
> this function is given to the libtpms, which in turn will call plain
> free() on it. I don't want this to cause a problem if not g_free()
> is called on this buffer.

Well, copy the data and malloc, or do something else,
must be easier than this manual loop.

> >>+
> >Separate options for fd and for file mode would be better.
> >
> initstate_fd=base64:<file descriptor>
> initstate_fd=bin:<file descriptor>
> initstate=base64:<path to file>
> initstate=bin:<path to file>
> 
> Along these lines?

No

initstate_fd=<file descriptor>
initstate_base64=on/off (or base64/bin if you really expect
	more formats in the future)

and use qemu routines to get the fd so they can be
passed through the monitor later ...


> Yes, that's a problem. Above would require bin:file:<path to blob>
> to be understood.
> 
>    Stefan

So avoid it. Give each option it's own flag.

-- 
MST