On 03/27/2013 02:27 PM, Anthony Liguori wrote:
Stefan Berger <stef...@linux.vnet.ibm.com> writes:
On 03/27/2013 01:14 PM, Anthony Liguori wrote:
Stefan Berger <stef...@linux.vnet.ibm.com> writes:
What I struggle with is that we're calling this a "blobstore". Using
BER to store "blobs" seems kind of pointless especially when we're
talking about exactly three blobs.
I suspect real hardware does something like, flash is N bytes, blob 1 is
a max of X bytes, blob 2 is a max of Y bytes, and blob 3 is (N - X - Y)
bytes.
Do we really need to do anything more than that?
I typically call it NVRAM, but earlier discussions seemed to prefer
'blobstore'.
Using BER is the 2nd design of the NVRAM/blobstore. The 1st one didn't
use any visitors but used a directory in the first sector pointing to
the actual blobs in other sectors of the block device. The organization
of the directory and assignment of the blobs to their sectors, aka 'the
layout of the data' in the disk image, was handled by the
NVRAM/blobstore implementation.
Okay, the short response is:
Just make the TPM have a DRIVE property, drop all notion of
NVRAM/blobstore, and used fixed offsets into the BlockDriverState for
each blob.
Fine by me. I don't see the need for visitors. I guess sharing of the
persistent storage between different types of devices is not a goal here
so that a layer that hides the layout and the blobs' position within the
storage would be necessary. Also fine by me for as long as we don't come
back to this discussion.
Stefan
