From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4D0n-00061t-Ts for qemu-devel@nongnu.org; Thu, 15 Sep 2011 10:33:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4D0f-0005eR-H4 for qemu-devel@nongnu.org; Thu, 15 Sep 2011 10:33:57 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]:40031) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4D0f-0005eI-AD for qemu-devel@nongnu.org; Thu, 15 Sep 2011 10:33:49 -0400 Received: from /spool/local by us.ibm.com with XMail ESMTP for from ; Thu, 15 Sep 2011 08:33:38 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p8FEXHem118124 for ; Thu, 15 Sep 2011 08:33:18 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p8FEWxo9000327 for ; Thu, 15 Sep 2011 08:32:59 -0600 Message-ID: <4E720CA9.9050208@linux.vnet.ibm.com> Date: Thu, 15 Sep 2011 10:33:13 -0400 From: Stefan Berger MIME-Version: 1.0 References: <20110915122842.GA6302@redhat.com> In-Reply-To: <20110915122842.GA6302@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] blobstore disk format (was Re: Design of the blobstore) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Anthony Liguori , QEMU Developers , Markus Armbruster On 09/15/2011 08:28 AM, Michael S. Tsirkin wrote: > So the below is a proposal for a directory scheme > for storing (optionally multiple) nvram images, > along with any metadata. > Data is encoded using BER: > http://en.wikipedia.org/wiki/Basic_Encoding_Rules > Specifically, we mostly use the subsets. > Would it change anything if we were to think of the NVRAM image as another piece of metadata? I am also wondering whether each device shouldn't just handle the metadata itself, so generate a blob from data structures containing all the metadata it needs, arranging attribute and value pairs itself (maybe using some convenience function for serialization/deserialization) and let the NVRAM layer not handle the metadata at all but only blobs, their maximum sizes, actual sizes encryption, integrity value (crc32 or sha1) and so on. What metadata should there be that really need to be handled on the NVRAM API and below level rather than on the device-specific code level? > We use a directory as a SET in a CER format. > This allows generating directory online without scanning > the entries beforehand. > I guess it is the 'unknown' for me... but what is the advantage of using ASN1 for this rather than just writing out packed and endianess-normalized data structures (with revision value), having them crc32-protected to have some sanity checking in place? Stefan > The rest of the encoding uses a DER format. > This makes for fast parsing as entries are easy to skip. > > Each entry is encoded in DER format. > Each entry is a SEQUENCE with two objects: > 1. nvram > 2. optional name - a UTF8String > > Binary data is stored as OCTET-STRING values on disk. > Any RW metadata is stored as OCTET-STRING value as well. > Any RO metadata is stored in appropriate universal encoding, > by type. > > On the context below, an attribute is either a IA5String or a SEQUENCE. > If IA5String, this is the attribute name, and it has no value. > If SEQUENCE, the first entry in the sequence is an > IA5String, it is the attribute name. The rest of the entries > represent the attribute value. > > Mandatory/optional attributes: depends on type. > tpm will have realsize as RW mandatory attribute. > > Each nvram is built as a SEQUENCE including 4 objects > 1. type - an IA5String. downstreams can use other types such as > UUIDs instead to ensure no conflicts with upstream > 2. SET of mandatory attributes > 3. SET of optional attributes > 4. data - a RW OCTET-STRING > > It is envisioned that attributes won't be too large, > so they can easily be kept in memory. > >