From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45694) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4B2e-0007St-IW for qemu-devel@nongnu.org; Thu, 15 Sep 2011 08:27:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4B2d-0007qS-4l for qemu-devel@nongnu.org; Thu, 15 Sep 2011 08:27:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14567) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4B2c-0007qO-QS for qemu-devel@nongnu.org; Thu, 15 Sep 2011 08:27:43 -0400 Date: Thu, 15 Sep 2011 15:28:43 +0300 From: "Michael S. Tsirkin" Message-ID: <20110915122842.GA6302@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] blobstore disk format (was Re: Design of the blobstore) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Berger Cc: Anthony Liguori , QEMU Developers , Markus Armbruster 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. We use a directory as a SET in a CER format. This allows generating directory online without scanning the entries beforehand. 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. -- MST