From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38693) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0FhZ-0007Jv-Us for qemu-devel@nongnu.org; Sun, 04 Sep 2011 12:37:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0FhY-0005gL-OU for qemu-devel@nongnu.org; Sun, 04 Sep 2011 12:37:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0FhY-0005gD-Eu for qemu-devel@nongnu.org; Sun, 04 Sep 2011 12:37:44 -0400 Date: Sun, 4 Sep 2011 19:38:14 +0300 From: "Michael S. Tsirkin" Message-ID: <20110904163814.GC12745@redhat.com> References: <20110831143551.127339744@linux.vnet.ibm.com> <20110831143625.419705972@linux.vnet.ibm.com> <20110901181024.GJ10989@redhat.com> <4E6046E8.60403@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E6046E8.60403@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH V8 14/14] Allow to provide inital TPM state List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Berger Cc: chrisw@redhat.com, anbang.ruan@cs.ox.ac.uk, qemu-devel@nongnu.org, rrelyea@redhat.com, alevy@redhat.com, andreas.niederl@iaik.tugraz.at, serge@hallyn.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: > initstate_fd=bin: > initstate=base64: > initstate=bin: > > Along these lines? No initstate_fd= 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: > to be understood. > > Stefan So avoid it. Give each option it's own flag. -- MST