[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170531094157.GA10511@lst.de>
Date: Wed, 31 May 2017 11:41:57 +0200
From: Christoph Hellwig <hch@....de>
To: David Howells <dhowells@...hat.com>
Cc: Christoph Hellwig <hch@....de>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Amir Goldstein <amir73il@...il.com>,
linux-fsdevel@...r.kernel.org, Shaohua Li <shli@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
Steven Whitehouse <swhiteho@...hat.com>,
Mimi Zohar <zohar@...ux.vnet.ibm.com>,
linux-xfs@...r.kernel.org, linux-raid@...r.kernel.org,
linux-nvdimm@...ts.01.org, linux-kernel@...r.kernel.org,
linux-block@...r.kernel.org, Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH 01/22] Revert "afs: Move UUID struct to linux/uuid.h"
On Tue, May 30, 2017 at 11:00:04AM +0100, David Howells wrote:
> This isn't going to work. You've effectively changed the types of the fields
> in the UUID struct from BE to CPU-endian, but you're still calling
> generate_random_uuid(), which produces a BE UUID. You need to leave the
> struct members as __beXX or stop using the core UUID routines.
>
> Just move the struct uuid_v1 as-is to the afs headers and rename it to struct
> afs_uuid. You can then leave the (un)marshalling code alone.
That's one option. The other option would be to revert
"afs: Use core kernel UUID generation", as that also changed the
v1 UUID to a v4 uuid. Does the afs protocol require a v1 uuid
or does it just use the formwat on the wire?
Powered by blists - more mailing lists