On Fri, 2016-02-26 at 16:11 +0200, Andy Shevchenko wrote:
Summon initial author of the UUID library.
Summary: the API of comparison functions is rather strange. What the point to not take pointers directly? (Moreover I hope compiler too clever not to make a copy of constant arguments there)
I could only imagine the case you are trying to avoid temporary variables for constants like NULL_UUID.
Issue with this is the ugliness in the users of that, in particularly present in ACPI (drivers/acpi/apei/ghes.c).
I would like to have more clear interface for that. Perhaps we may add something like
cmp_p(pointer, non-pointer); cmp_pp(pointer, pointer);
to not break existing API for now.
It would be useful for many cases in the kernel.
Andy Shevchenko andriy.shevchenko@linux.intel.com writes:
You can take a look at the drivers/acpi/apei/erst.c for uuid_le_cmp usage.
#define CPER_CREATOR_PSTORE \ UUID_LE(0x75a574e3, 0x5052, 0x4b29, 0x8a, 0x8e, 0xbe, 0x2c, \ 0x64, 0x90, 0xb8, 0x9d)
if (uuid_le_cmp(rcd->hdr.creator_id, CPER_CREATOR_PSTORE) != 0) goto skip;
Looks better?
This is the typical use case in mind when I write the uuid.h.
As for uuid_le_cmp usage in drivers/acpi/apei/ghes.c,
if (!uuid_le_cmp(*(uuid_le *)gdata->section_type, CPER_SEC_PLATFORM_MEM)) {
The code looks not good mainly because acpi_hest_generic_data is not defined with uuid_le in mind.
struct acpi_hest_generic_data { u8 section_type[16]; u32 error_severity; u16 revision; u8 validation_bits; u8 flags; u32 error_data_length; u8 fru_id[16]; u8 fru_text[20]; };
If section_type was defined as uuid_le instead of u8[16], the uuid_le_cmp usage would look better. So I suggest to use uuid_le/be in data structure definition in new code if possible.
Best Regards, Huang, Ying
dri-devel@lists.freedesktop.org