From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44254) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOuwM-00064r-Cv for qemu-devel@nongnu.org; Wed, 25 Sep 2013 15:40:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VOuwD-0003oH-MX for qemu-devel@nongnu.org; Wed, 25 Sep 2013 15:40:02 -0400 Received: from mail-ob0-x230.google.com ([2607:f8b0:4003:c01::230]:45258) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VOuwD-0003oA-HJ for qemu-devel@nongnu.org; Wed, 25 Sep 2013 15:39:53 -0400 Received: by mail-ob0-f176.google.com with SMTP id uy5so294172obc.35 for ; Wed, 25 Sep 2013 12:39:53 -0700 (PDT) Sender: Richard Henderson Message-ID: <52433C04.3060101@twiddle.net> Date: Wed, 25 Sep 2013 12:39:48 -0700 From: Richard Henderson MIME-Version: 1.0 References: <61a5c47913cce201bbea67a973544805f7b13947.1379615569.git.jcody@redhat.com> <523B4A04.80109@twiddle.net> <20130920041812.GJ15106@localhost.localdomain> <87vc1wyps5.fsf@blackfin.pond.sub.org> <20130925151236.GC5035@localhost.localdomain> <20130925172520.GH2898@dhcp-200-207.str.redhat.com> <20130925190100.GD5035@localhost.localdomain> In-Reply-To: <20130925190100.GD5035@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/5] block: cow - used QEMU_PACKED for on-disk structures List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Cody Cc: Kevin Wolf , Markus Armbruster , stefanha@redhat.com, qemu-devel@nongnu.org On 09/25/2013 12:01 PM, Jeff Cody wrote: > It is from UML, right? Is there an official spec that is still around > (most of the links I have found suffer from link rot)? The closest I > could find to a spec were old UML patches for x86_64 that cleaned up > some data types, so that the following was defined: > > struct cow_header_v2 { > __u32 magic; > __u32 version; > char backing_file[PATH_LEN_V2]; > time_t mtime; > __u64 size; > int sectorsize; > }; > > That remains ambiguous, although given the era I suppose it could be > argued that 32-bit architecture and alignment is assumed. But if this > is the original spec, then it seems like a non-portable one. Indeed. Not just the potential padding there, but of course the size of time_t varies between hosts. And since we use an int32_t not time_t, we're not even necessarily compatible with UML. r~