Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp121395ybt; Thu, 25 Jun 2020 17:02:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx9j9uroFzLQwLRe3VMMfKXYpg+h03SVhVUQXUzxlD8kktU6tbnwNyGB+rzvANUhFz/eYn3 X-Received: by 2002:a17:906:bb0c:: with SMTP id jz12mr244248ejb.27.1593129750387; Thu, 25 Jun 2020 17:02:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593129750; cv=none; d=google.com; s=arc-20160816; b=vmx1My5Yv9jtOOW3nKzuRZBw1fUGANRoF4cGRx4Ygf3pzc3q5qO60EM2kuyhn6mitD ZqCYXKwNEnNy3GbBHSX+TxLmH9WDxO8EzFsTYfZ1Z0wg/Kn0tAmr/Zsa51KAtqjlV8FO 00d12j7PY4Iup4RDoTEWEj/EDeQh7cXOs390gphWu0IJV4/1ksWPbB0w6otwWumXdD+q PL2AmyAeXMuWaezYp01529gvwuoIryc25P4OeGCl8LHjxqclS6vjQBSK6rJbgd35+DX9 ENFquRcpNa1vR8xn2RvobpTbMB4hc4qgOMt5WmgbjlyT3lRoo+Hwdz+c/ZMUOdJMabEX cHDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature:dkim-signature; bh=85zqKQM4wdc6ALY2QE5fZtnJILsou/26edZ1hekQfPg=; b=CTWDMrTlLEf7XuD60r0iWxTNljEH2vVx+9UA7lVLfXlQW3WV+cNvPBEGy1UZS/vwUN Tfy1fJuS2M3/Z/oac69aYIZo6/gitDkmkq0vztvkuMT10rSPbup4298xeAXubgoo6/kc lym1qr8dMmZpHC1IarIUWbdHE245rwYzrR/EjLWVI4VolYhMov3zbvhbUoga/OsSGrk0 h3/aQsv0OlOT8QKr1zO0KIIma6aV5+rP/Yr0vl96lEc1Nf5EhdkMtGcYrPcDzIFWmNsw 6zie+r7f/2Yd8IR4giLNcaYV3DSzB4tl38Il9B0qu1bswm67CktrGi8xLCzTw8GDhtd7 CMxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=uHylQH0y; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=uHylQH0y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o2si16962828edd.477.2020.06.25.17.02.07; Thu, 25 Jun 2020 17:02:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=uHylQH0y; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=uHylQH0y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725792AbgFYXbq (ORCPT + 99 others); Thu, 25 Jun 2020 19:31:46 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:43730 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725554AbgFYXbq (ORCPT ); Thu, 25 Jun 2020 19:31:46 -0400 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id E43448EE2F6; Thu, 25 Jun 2020 16:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1593127904; bh=3t2rEmrXunzbuoRIHJIfGmnQexOBzUIBYGc01ozpYJQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=uHylQH0yQbxU0l7k9WCjEDc9QURr3VnCrOBLZ3jdZf96C4DzQ1Q3djOdmatw+EU4C VeSmPX7KP1V/FxEMUwDEEvmTAOiD0urCQdMX1IuZdo6pVBWA3fXEJFmF+YJ6x+Kwif hVPS7qHrQJyfk4K69CbssfaIBbGiQjjEMOCwfG28= Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9twK_fggstL; Thu, 25 Jun 2020 16:31:44 -0700 (PDT) Received: from [153.66.254.194] (unknown [50.35.76.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 7FAAB8EE079; Thu, 25 Jun 2020 16:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1593127904; bh=3t2rEmrXunzbuoRIHJIfGmnQexOBzUIBYGc01ozpYJQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=uHylQH0yQbxU0l7k9WCjEDc9QURr3VnCrOBLZ3jdZf96C4DzQ1Q3djOdmatw+EU4C VeSmPX7KP1V/FxEMUwDEEvmTAOiD0urCQdMX1IuZdo6pVBWA3fXEJFmF+YJ6x+Kwif hVPS7qHrQJyfk4K69CbssfaIBbGiQjjEMOCwfG28= Message-ID: <1593127902.13253.11.camel@HansenPartnership.com> Subject: Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry From: James Bottomley To: Sumit Garg Cc: Jerome Forissier , Maxim Uvarov , Greg Kroah-Hartman , Linux Kernel Mailing List , Jarkko Sakkinen , Arnd Bergmann , "tee-dev @ lists . linaro . org" , Jason Gunthorpe , linux-integrity@vger.kernel.org, peterhuewe@gmx.de Date: Thu, 25 Jun 2020 16:31:42 -0700 In-Reply-To: References: <20200604175851.758-1-maxim.uvarov@linaro.org> <20200604175851.758-2-maxim.uvarov@linaro.org> <1592507935.15159.5.camel@HansenPartnership.com> <1592578844.4369.5.camel@HansenPartnership.com> <1593012069.28403.11.camel@HansenPartnership.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2020-06-25 at 19:54 +0530, Sumit Garg wrote: > On Wed, 24 Jun 2020 at 20:51, James Bottomley > 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 > > > 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? If we did #define uuid_le_t guid_t would you be happy? (not that the kernel cares about karmic emotional states either ...) James