On Fri, Jun 26, 2020 at 08:11:21AM -0700, James Bottomley wrote: > On Fri, 2020-06-26 at 12:29 +0100, Daniel Thompson wrote: > > On Fri, Jun 26, 2020 at 10:40:41AM +0530, Sumit Garg 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/ke > > > rnel/ree_fs_ta.c#L92 > > > > I'm struck that all references here are to code that does not run in > > kernel space. Frankly on LKML I don't know if we should even *care* > > what format UUIDs are stored in other address spaces. > > > > We care about is the endianness of the UUID on the interface > > boundaries into and out of the kernel[1] and we care that we use the > > correct kernel type to describe it. > > > > I understood from Jerome's post that the UUID that the kernel > > manipulates are, in fact, big endian and that they should be called > > uuid_t. > > > > Is there more going on here or is that it? > > As you say, a UUID to the kernel is a binary blob except for input, > which to the kernel is INIT_UUID or INIT_GUID and output, which is > either printk %Ub for uuid_t or %Ul for guid_t. > > The bit I objected to was doing a %Ul on a uuid_t because it's going to > trip the static checkers. That shows me there's a confusion in the > code between little and big endian UUID types, but I haven't looked > further than that. Thanks for bringing our attention to this, it was educating for me at least. It seems the only problem was just the %Ul that should have been a %Ub. The OP-TEE driver is only dealing with BE UUIDs internallay and in the ABIs to user space and secure world. I agree with Daniel, what happens in user space and in secure world isn't of interest here as long as the ABIs are OK. Cheers, Jens
