Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH 1/2] afs: Move UUID struct to linux/uuid.h | Date | Thu, 12 Jan 2017 14:12:56 +0000 |
| |
Arnd Bergmann <arnd@arndb.de> wrote:
> Looks good to me, but I wonder if this part: > > r = call->request; > - r->time_low = ntohl(b[0]); > - r->time_mid = ntohl(b[1]); > - r->time_hi_and_version = ntohl(b[2]); > + r->time_low = b[0]; > + r->time_mid = htons(ntohl(b[1])); > + r->time_hi_and_version = htons(ntohl(b[2])); > r->clock_seq_hi_and_reserved = ntohl(b[3]); > r->clock_seq_low = ntohl(b[4]); > > should be considered a bugfix and split out into a > separate patch.
I changed the definitions in the struct from u16/u32 to __be16/__be32 so it's not a bugfix.
For some reason, rather than specifying UUIDs as just a 16-octet field, the AFS protocol breaks the UUID down into pieces and converts them into 32-bit fields (apparently signed in some places:-/).
> From what I understand about the mess in UUID formats, the time fields can > either be big-endian (as defined) or little-endian (for all things > Microsoft),
RFC 4122 specified that the multi-octet fields are stored MSB-first.
> and you are changing the representation from CPU-specific to big-endian, > which makes it different for x86 and most ARM at least.
In-kernel, not in the protocol.
The problem is that you can't do what you put in your suggested patch and just copy the UUID produced by the generate_random_uuid() over the afs_uuid struct since that puts the version in the wrong place.
David
| |