Messages in this thread | | | From | Andy Lutomirski <> | Date | Wed, 30 Aug 2017 13:01:28 -0700 | Subject | Re: [PATCH v1] platform/x86: wmi: Switch to use new generic UUID API |
| |
On Wed, Aug 30, 2017 at 5:25 AM, Christoph Hellwig <hch@lst.de> 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
| |