> Am 04.03.2014 um 03:58 schrieb Jeff Cody <[email protected]>: > >> On Fri, Feb 21, 2014 at 01:06:43PM +0100, Alexander Graf wrote: >> >>> On 08.11.2013, at 11:12, Stefan Hajnoczi <[email protected]> wrote: >>> >>> From: Jeff Cody <[email protected]> >>> >>> This adds support for VHDX image creation, for images of type "Fixed" >>> and "Dynamic". "Differencing" types (i.e., VHDX images with backing >>> files) are currently not supported. >>> >>> Options for image creation include: >>> * log size: >>> The size of the journaling log for VHDX. Minimum is 1MB, >>> and it must be a multiple of 1MB. Invalid log sizes will be >>> silently fixed by rounding up to the nearest MB. >>> >>> Default is 1MB. >>> >>> * block size: >>> This is the size of a payload block. The range is 1MB to 256MB, >>> inclusive, and must be a multiple of 1MB as well. Invalid sizes >>> and multiples will be silently fixed. If '0' is passed, then >>> a sane size is chosen (depending on virtual image size). >>> >>> Default is 0 (Auto-select). >>> >>> * subformat: >>> - "dynamic" >>> An image without data pre-allocated. >>> - "fixed" >>> An image with data pre-allocated. >>> >>> Default is "dynamic" >>> >>> When creating the image file, the lettered sections are created: >>> >>> -----------------------------------------------------------------. >>> | (A) | (B) | (C) | (D) | (E) >>> | File ID | Header1 | Header 2 | Region Tbl 1 | Region Tbl 2 >>> | | | | | >>> .-----------------------------------------------------------------. >>> 0 64KB 128KB 192KB 256KB 320KB >>> >>> .---- ~ ----------- ~ ------------ ~ ---------------- ~ -----------. >>> | (F) | (G) | (H) | >>> | Journal Log | BAT / Bitmap | Metadata | .... data ...... >>> | | | | >>> .---- ~ ----------- ~ ------------ ~ ---------------- ~ -----------. >>> 1MB (var.) (var.) (var.) >>> >>> Signed-off-by: Jeff Cody <[email protected]> >>> Signed-off-by: Stefan Hajnoczi <[email protected]> >>> --- >>> block/vhdx.c | 558 >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> block/vhdx.h | 15 +- >>> 2 files changed, 572 insertions(+), 1 deletion(-) >> >> [..…] >> >>> /* Header for the region table block */ >>> +#define VHDX_REGION_SIGNATURE 0x69676572 /* "regi" in ASCII */ >>> typedef struct QEMU_PACKED VHDXRegionTableHeader { >>> uint32_t signature; /* "regi" in ASCII */ >>> uint32_t checksum; /* CRC-32C hash of the 64KB table */ >>> @@ -238,6 +247,7 @@ typedef uint64_t VHDXBatEntry; >>> #define VHDX_METADATA_MAX_ENTRIES 2047 /* not including the header */ >>> #define VHDX_METADATA_TABLE_MAX_SIZE \ >>> (VHDX_METADATA_ENTRY_SIZE * (VHDX_METADATA_MAX_ENTRIES+1)) >>> +#define VHDX_METADATA_SIGNATURE 0x617461646174656D /* "metadata" in ASCII >>> */ >> >> This is missing a "ULL" tag. There are a few places where compilation of >> vhdx spawns warnings on 32bit hosts - I haven't checked all of them. >> >> 02/21 12:22:14 ERROR| utils:0144| [stderr] block/vhdx.c: In function >> 'vhdx_open': >> 02/21 12:22:14 ERROR| utils:0144| [stderr] block/vhdx.c:957: warning: >> integer constant is too large for 'long' type >> 02/21 12:22:14 ERROR| utils:0144| [stderr] block/vhdx.c: In function >> 'vhdx_block_translate': >> 02/21 12:22:14 ERROR| utils:0144| [stderr] block/vhdx.c:1027: warning: >> integer constant is too large for 'long' type >> 02/21 12:22:14 ERROR| utils:0144| [stderr] block/vhdx.c: In function >> 'vhdx_create_new_metadata': >> 02/21 12:22:14 ERROR| utils:0144| [stderr] block/vhdx.c:1455: warning: >> integer constant is too large for 'long' type >> 02/21 12:22:14 ERROR| utils:0144| [stderr] block/vhdx.c: In function >> 'vhdx_create': >> 02/21 12:22:14 ERROR| utils:0144| [stderr] block/vhdx.c:1812: warning: >> integer constant is too large for 'long' type > > Hi Alex, > > I've compiled this using both i686/i386 Fedora 20 and OpenSuse 13.1 > hosts, and I did not run into these warnings. Could you tell me what > host and compiler you are using for compilation, so I can reproduce > and verify the fix?
In this particular case I was running ppc32 openSUSE 11.1. i'm surprised you don't see it on newer versions though. Alex > > > Thanks, > Jeff
