From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Dorminy Subject: Re: [PATCH 3/4] dm-zoned: V2 metadata handling Date: Thu, 2 Apr 2020 11:52:42 -0400 Message-ID: References: <20200327071459.67796-1-hare@suse.de> <20200327071459.67796-4-hare@suse.de> <93a26ed9-6f6e-2a4d-38d3-3fb76fa91e70@oracle.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3385845115185588383==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Hannes Reinecke Cc: Bob Liu , device-mapper development , Damien LeMoal , Mike Snitzer List-Id: dm-devel.ids --===============3385845115185588383== Content-Type: multipart/alternative; boundary="000000000000264df105a250cb46" --000000000000264df105a250cb46 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That does make sense. May I request, then, using UUID_SIZE instead of 16? Perhaps with a compile-time assertion that UUID_SIZE has not change from 16= ? On Thu, Apr 2, 2020 at 11:10 AM Hannes Reinecke wrote: > On 4/2/20 4:53 PM, John Dorminy wrote: > > I'm worried about hardcoding uuid members as u8[16]. > > > > May I ask why you're not using uuid_t to define it in the on-disk > > structure? It would save the casting of the uuid members to (uuid_t *) > > every time you use a uuid.h function. > > > > Possibly it is customary to use only raw datatypes on disk rather than > > opaque types like uuid_t, I'm not sure. But in that case, perhaps using > > the named constant UUID_SIZE instead of 16 would make the meaning > clearer? > > > I prefer to use absolute types (like __u8) when describing the on-disk > format. > When using opaque types like uuid_t there always is the risk that the > internal representation will change, leading to an involuntary change of > the on-disk format structure and subsequent compability issues. > > Cheers, > > Hannes > -- > Dr. Hannes Reinecke Teamlead Storage & Networking > hare@suse.de +49 911 74053 688 > SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg > HRB 36809 (AG N=C3=BCrnberg), Gesch=C3=A4ftsf=C3=BChrer: Felix Imend=C3= =B6rffer > > --000000000000264df105a250cb46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That does make sense. May I request, then, using UUID_SIZE= instead of 16? Perhaps with a compile-time assertion that UUID_SIZE has no= t change from 16?

On Thu, Apr 2, 2020 at 11:10 AM Hannes Reinecke <hare@suse.de> wrote:
On 4/2/20 4:53 PM, John Dorminy w= rote:
> I'm worried about hardcoding uuid members as u8[16].
>
> May I ask why you're not using uuid_t to define it in the on-disk =
> structure? It would save the casting of the uuid members to (uuid_t *)=
> every time you use a uuid.h function.
>
> Possibly it is customary to use only raw datatypes on disk rather than=
> opaque types like uuid_t, I'm not sure. But in that case, perhaps = using
> the named constant UUID_SIZE instead of 16 would make the meaning clea= rer?
>
I prefer to use absolute types (like __u8) when describing the on-disk
format.
When using opaque types like uuid_t there always is the risk that the
internal representation will change, leading to an involuntary change of the on-disk format structure and subsequent compability issues.

Cheers,

Hannes
--
Dr. Hannes Reinecke=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Teamlead Stora= ge & Networking
hare@suse.de=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg
HRB 36809 (AG N=C3=BCrnberg), Gesch=C3=A4ftsf=C3=BChrer: Felix Imend=C3=B6r= ffer

--000000000000264df105a250cb46-- --===============3385845115185588383== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============3385845115185588383==--