From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 120B7C433E0 for ; Fri, 26 Jun 2020 08:47:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DB27220773 for ; Fri, 26 Jun 2020 08:47:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="VHQ0XxB8" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725876AbgFZIrx (ORCPT ); Fri, 26 Jun 2020 04:47:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47206 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725841AbgFZIrx (ORCPT ); Fri, 26 Jun 2020 04:47:53 -0400 Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 275ACC08C5C1; Fri, 26 Jun 2020 01:47:53 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id q17so4363509pfu.8; Fri, 26 Jun 2020 01:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JI/FNcwdyAdin6Ur1Q7aBKHSJFRVIajQTwQ7ldYrmC8=; b=VHQ0XxB8CemNyEW0YECC8FE3K9egsL2tOTVGWMGaeuV0MgtUDhU8VIFX/eHRvAVJqk Cnw8D+eieVeLnHM8yH+bSsmAd/sMX684rTaFJ5kSycvbLZAa6JPhGO4xflp7E506KY14 2bG0xv4Vqlm9Y4T0fQz5L9I4Kr7LQh2GCJhbNmTk7Jj8M1mpv6Vtiz1gyZx8ZwxpVl/8 gm9g/mRMU2Ol0Ks7bn8UZxnDUj2JpEmFAER7fPJ38AR/v6fXCyJ3Y4ZwgluwTa1gS7ew 1bdztItqfrWThqsVpntoxvDDH54RzgXcCQV+pBg39qkBckMY4agtwgezElS9iGvUoGLH w+UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JI/FNcwdyAdin6Ur1Q7aBKHSJFRVIajQTwQ7ldYrmC8=; b=FoxFwvvTq08ef+olJRqa2YEd1fs8WCSMDoEMJd0zUp5/W6NNvzuOI4S67hx+Ia4oIw VhJUgOgNdDSH5uiIZppJinG+MrvUqbQnHVNCOHuN3Q7WUpAQWHl+KO4CdF++h8mWoIlx Fh0VP+UmrnJzoInZzr/RPZUnEvN/nVChNicj0LHgceMDo4oUuPhfDLssq8IAbe0k2UMd pcVu3aBlcp/fX/QsLQr/cIwVUgCnc8WTFlq9qjsNYuvwwlvNNBJDCUuwarvL3FjFbHoQ Ev3v9p39ZKI3Fn4m4eNkQuVM3dJcGX4Acf182BbVx37h02ECnxZPZzDrHzY0YE4dPor+ hLlQ== X-Gm-Message-State: AOAM5305vZ97xH2/AOjeZvZGD57MBs+99Bi4CBQ4LvW+qzQNIY8DQNFJ PLubJ6E0qHvy2VSVA78r+wU/ZHHYd8cDAHJP+BU= X-Google-Smtp-Source: ABdhPJyzcy/EnnkJVkh4VCmUDv0EuqOkP7T5Q9t74koNfxidVlOE5ZRRJE1H+NyHSzDnj/A8bDCDmE4h7sIlVdqv3ZE= X-Received: by 2002:a63:924b:: with SMTP id s11mr1766606pgn.74.1593161272465; Fri, 26 Jun 2020 01:47:52 -0700 (PDT) MIME-Version: 1.0 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> <3aa8705a-0342-25ea-00c4-d5370d91ddb4@forissier.org> In-Reply-To: From: Andy Shevchenko Date: Fri, 26 Jun 2020 11:47:36 +0300 Message-ID: Subject: Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry To: Sumit Garg Cc: Maxim Uvarov , Jerome Forissier , James Bottomley , Greg Kroah-Hartman , Linux Kernel Mailing List , Jarkko Sakkinen , Arnd Bergmann , "tee-dev @ lists . linaro . org" , Jason Gunthorpe , linux-integrity , peterhuewe@gmx.de Content-Type: text/plain; charset="UTF-8" Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org On Fri, Jun 26, 2020 at 8:18 AM Sumit Garg wrote: > On Thu, 25 Jun 2020 at 18:22, Maxim Uvarov wrote: ... > I guess you missed the point that uuid_t is implemented in BE format > in the kernel which is compliant as per RFC 4122. I guess you missed the point. Kernel doesn't have anything special about these types and does NOT compliant as per RFC. The only things the kernel distinguishes are a) byte order (always), and b) version bits when you get a random UUID (whatever you call it). I guess this discussion takes too much time. The idea is that kernel types are just for kernel use with as little intrusion as possible. The main principle, we get something, we carry it w/o modifications inside the kernel. So, you may use whatever you want and LE/BE is purely based on a) and b) above. -- With Best Regards, Andy Shevchenko