From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1YsOd6-0005yA-VK for mharc-grub-devel@gnu.org; Wed, 13 May 2015 00:50:48 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsOd2-0005w2-Ti for grub-devel@gnu.org; Wed, 13 May 2015 00:50:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YsOcz-0005fy-Ob for grub-devel@gnu.org; Wed, 13 May 2015 00:50:44 -0400 Received: from mail-lb0-x231.google.com ([2a00:1450:4010:c04::231]:34693) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsOcz-0005fs-Fb for grub-devel@gnu.org; Wed, 13 May 2015 00:50:41 -0400 Received: by lbcga7 with SMTP id ga7so20940558lbc.1 for ; Tue, 12 May 2015 21:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=5ijy/8iy86y9XARQza05hRLqX8wz7pn+dFVMSf4XfCs=; b=uFtoBje2whNbX1Lx1qXUkycRHbPq1Vj2Xn1wNBecJLUcRK6fAc98EmFuwgGf4fOP3q yHtLqYHFJJPnnfmKcfXdjHfyXr4q8MkiptS7J5j5Gm8u5jO5kNxOwUtZyVeZ37CR6p83 fvjXjlJAjI+8q3GS/Ely+JQRdjL2Od3mlSz8yOwZEXElB628APvW7/IlLUV1wqxdRKmb iXLGnN5ydaDZRkIpRro5EaqH9MKBTkcrRuS7hv+RAAAVt9MCz5eRMsGTvZKsyu9Zp1gU hgP6VP0hLRUI1il9A7qMY624aMuRpTbjmUfrIPTt2pxpmQQ2I6eaRzc6gfBhkXv4Gj7K H5YQ== X-Received: by 10.112.119.163 with SMTP id kv3mr14713608lbb.101.1431492640565; Tue, 12 May 2015 21:50:40 -0700 (PDT) Received: from opensuse.site (ppp91-76-14-38.pppoe.mtu-net.ru. [91.76.14.38]) by mx.google.com with ESMTPSA id dc7sm4537131lad.22.2015.05.12.21.50.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2015 21:50:39 -0700 (PDT) Date: Wed, 13 May 2015 07:50:38 +0300 From: Andrei Borzenkov To: Jan Kara Subject: Re: [PATCH 4/4] xfs: V5 filesystem format support Message-ID: <20150513075038.1b20f613@opensuse.site> In-Reply-To: <20150512134740.GA20095@quack.suse.cz> References: <1405351291-24767-1-git-send-email-jack@suse.cz> <1405351291-24767-5-git-send-email-jack@suse.cz> <20150512082340.78aa6ee5@opensuse.site> <20150512134740.GA20095@quack.suse.cz> X-Mailer: Claws Mail 3.11.0 (GTK+ 2.24.27; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::231 Cc: The development of GNU GRUB X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 04:50:45 -0000 =D0=92 Tue, 12 May 2015 15:47:40 +0200 Jan Kara =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > +{ > > > + return ((grub_uint8_t *)(de + 1)) + de->len - 1 + > > The outer parens are somehow confusing. >=20 > I can remove them but I find it better to explicitely show where the > typecast happens with parenthesis... >=20 OK > > + > > > +static grub_uint64_t * > > > +grub_xfs_btree_keys(struct grub_xfs_data *data, > > > + struct grub_xfs_btree_node *leaf) > > > +{ > > > + char *p =3D (char *)(leaf + 1); > > > + > > > + if (data->hascrc) > > > + p +=3D 48; /* crc, uuid, ... */ > > > + /* > > > + * We have to first type to void * to avoid complaints about possi= ble > > > + * alignment issues on some architectures > > > + */ > > > + return (grub_uint64_t *)(void *)p; > >=20 > > Leaving it as grub_uint64_t keys and using &keys[6] would avoid this > > warning as well, not? Also having keys[0] will likely simplify other > > places as well (we do require GCC in any case). >=20 > Well, the trouble with this is that we'd need two structures defined - > one for crc-enabled fs and one for old fs. That seemed like a wasted effo= rt > to me when we could do: > if (data->hascrc) > p +=3D 48; /* crc, uuid, ... */ > like the above. The same holds for inodes, directory entries, etc. I'd > prefer not to bloat the code with structure definitions we don't actually > use but if you really insisted, I could do that. So what do you think? Why 2 structures? What I actually meant was struct grub_xfs_btree_node { grub_uint8_t magic[4]; grub_uint16_t level; grub_uint16_t numrecs; grub_uint64_t left; grub_uint64_t right; grub_uint64_t keys[0]; } GRUB_PACKED; if (data->hascrc) return &leaf->keys[6] else return &leaf->keys[0] with suitable comment. It is not perfect either but at least leaves compiler check in place.