Re: [PATCH] test: lib/uuid: Fix endianness for dynamic GUIDs

On 8/27/26 16:08, Alexey Charkov wrote:
> On Thu, Aug 27, 2026 at 5:39 PM Heinrich Schuchardt
> <[email protected]> wrote:
>>
>> On 8/27/26 15:00, Alexey Charkov wrote:
>>> If LIB_UUID is enabled on a big-endian board, such as when it is pulled
>>> in by EFI_PARTITION, its tests will fail due to the dynamic capsule GUIDs
>>> computed by lib_test_dynamic_uuid() using native endianness for the UTF-16
>>> image name, instead of little-endian:
>>>
>>>     malta # ut lib lib_test_dynamic_uuid
>>>     Test: dynamic_uuid: uuid.c
>>>     test/lib/uuid.c:114, lib_test_dynamic_uuid_case(): expected_uuid = uuid_str: Expected "985f2937-7c2e-5e9a-8a5e-8e063312964b", got "829f5cb0-1a07-5718-8774-4514bda82c39"
>>>     Test 'dynamic_uuid' failed 1 times
>>>     Tests run: 1, 2 ms, average: 2 ms, failures: 1
>>>     exit not allowed from main input shell.
>>>     malta #
>>>
>>> Add explicit endianness conversion to the test and to other similar
>>> callers of gen_v5_guid() to make sure they work uniformly regardless of
>>> the host or target endianness.
>>>
>>> Signed-off-by: Alexey Charkov <[email protected]>
>>
>> Thank you for reporting that the test fails on big endian systems.
>>
>> In lib_test_dynamic_uuid() we define define dynamic_uuid_test_data
>> test_data[].images as u16 string. On a big endian system the characters
>> of the string will not be stored in the same sequence as on a low endian
>> system so the UUID generated in gen_v5_guid() is expected to be different.
>>
>> test_data[].images should contain unique sequences of bytes.
>>
>> The relevant code was introduced with
>> 26e16a850e64 ("test: lib/uuid: add unit tests for dynamic UUIDs")
> 
> Thanks for looking into this!
> 
> Do I get it right that you'd rather have the test_data[].images bytes
> untouched, and instead select different test_data[].expected_uuids
> based on the CPU endianness, rather than patching
> lib_test_dynamic_uuid_case()? Or shall I make the test_data[].images a
> plain byte array to remove the endianness concern altogether?

I would prefer to define the images field as char[].

u16 images[] = u"QUALCOMM-UBOOT" would become
char images[] = "Q\0U\0A\0L\0C\0O\0M\0M\0-\0U\0B\0O\0O\0T\0\0"

Best regards

Heinrich

> 
>> With that I don't think that the EFI changes are needed. Anyway UEFI is
>> little endian only.
> 
> Happy to drop the hunks touching files other than the test
> expectation. However, the test expectation needs an update one way or
> another, as we can't test GPT on BE without it.
> 
> Best regards,
> Alexey