On Fri, 26 Jun 2020 at 10:40, Sumit Garg <sumit.garg@xxxxxxxxxx> wrote: > > On Fri, 26 Jun 2020 at 05:01, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Thu, 2020-06-25 at 19:54 +0530, Sumit Garg wrote: > > > On Wed, 24 Jun 2020 at 20:51, James Bottomley > > > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Wed, 2020-06-24 at 16:17 +0530, Sumit Garg wrote: > > > > > Apologies for delay in my reply as I was busy with some other > > > > > stuff. > > > > > > > > > > On Fri, 19 Jun 2020 at 20:30, James Bottomley > > > > > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > [...] > > > > > > it's about consistency with what the kernel types mean. When > > > > > > some checker detects your using little endian operations on a > > > > > > big endian structure (like in the prink for instance) they're > > > > > > going to keep emailing you about it. > > > > > > > > > > As mentioned above, using different terminology is meant to cause > > > > > more confusion than just difference in endianness which is > > > > > manageable inside TEE. > > > > > > > > > > And I think it's safe to say that the kernel implements UUID in > > > > > big endian format and thus uses %pUb whereas OP-TEE implements > > > > > UUID in little endian format and thus uses %pUl. > > > > > > > > So what I think you're saying is that if we still had uuid_be and > > > > uuid_le you'd use uuid_le, because that's exactly the structure > > > > described in the docs. But because we renamed > > > > > > > > uuid_be -> uuid_t > > > > uuid_le -> guid_t > > > > > > > > You can't use guid_t as a kernel type because it has the wrong > > > > name? > > > > > > Isn't the rename commit description [1] pretty clear about which is > > > the true UUID type from Linux point of view? > > > > I don't think the kernel code takes a position on eternal verity, just > > on logical or arithmetic truth. We just have to deal with both LE and > > BE UUIDs so we have appropriate types for them and the LE type is now > > named guid_t. They're both equally correct to use provided the use > > case matches the designed one. So does the name really matter? > > Yes it does. I guess I have provided enough reasoning for that. Also, > the rename commit itself illustrates its importance and clarifies the > use case for which they are meant to be used. > > > If we > > did > > > > #define uuid_le_t guid_t > > > > would you be happy? (not that the kernel cares about karmic emotional > > states either ...) > > It's not about me being happy but more about confusion and > inconsistency it will bring. > > IMO, either kernel should be opinionated about UUID endianness like > currently it is: > > uuid_t and its corresponding helpers (eg. UUID_INIT) follows BE format. > > or support both endianness for UUID (no common type: uuid_t) like we > had earlier prior to rename commit: > > uuid_be_t and its corresponding helpers (eg. UUID_BE_INIT) follow BE format. > uuid_le_t and its corresponding helpers (eg. UUID_LE_INIT) follow LE format. > > But even if we consider later case as well, I am still not sure if we > can switch to uuid_le_t as it's been part of TEE core ABI > (open_session) where UUID is passed in BE format (see LE to BE > conversion in TEE client [1] and vice-versa in OP-TEE OS [2]) and > won't be a backwards compatible change. > > [1] https://github.com/OP-TEE/optee_client/blob/master/libteec/src/tee_client_api.c#L595 > [2] https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/kernel/ree_fs_ta.c#L92 Sorry, the second reference is incorrect, correct one is: [2] https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/tee/entry_std.c#L279 -Sumit > > -Sumit > > > > > James > >
