Re: [PATCH v1] platform/x86: wmi: Switch to use new generic UUID API

[Andy Lutomirski]

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