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
