On Wed, Aug 30, 2017 at 5:25 AM, Christoph Hellwig <hch@xxxxxx> wrote: > On Sun, Aug 13, 2017 at 08:34:56AM -0700, Andy Lutomirski wrote: >> > This specification defines a Uniform Resource Name namespace for >> > UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally >> > Unique IDentifier). >> >> No, that still matches what I thought I knew: "UUID" and "GUID" are synonyms. > > Well, in practice they aren't - wintel GUID are big endian, and > RFC4122 clearly states it is big endian, although it uses the term > "network byte order": What I'm saying is: I agree that "RFC4122 UUID" and "wintel GUID" are different, but the new structs aren't called "RFC4122 UUID" and "wintel GUID" - they're called "uuid" and "guid". I think the latter is very far from intuitive. I read the wmi patches several times before I figured out that they were even potentially correct. >> >> typedef whatever uuid_t; >> typedef something_different uuid_le; /* which already existed */ >> >> extern void uuid_le_to_uuid(uuid_t *out, uuid_le *in); >> extern void uuid_to_uuid_le(...); > > What's the point of converting between a RFC4122 UUID and a Wintel > GUID? They are used for entirely different things. I can see at least two clean ways to design the API: 1. Make them totally separate. Have a function to convert a string to a uuid_le (or a guid_le or whatever you want to call it, as long as "le" or perhaps "wintel" is involved so it's obvious.) Have another function to convert back. Teach printk to understand %pULE. 2. Have a function to convert back and forth so that kernel code uses the real RFC4122 UUID for internal representations and keep just %pU. --Andy
