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=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 4EDF7C433E2 for ; Wed, 9 Sep 2020 07:07:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D72CE21532 for ; Wed, 9 Sep 2020 07:07:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=kroah.com header.i=@kroah.com header.b="E+bYY3r6"; dkim=temperror (0-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="q9zKpoqq" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725826AbgIIHHX (ORCPT ); Wed, 9 Sep 2020 03:07:23 -0400 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:34915 "EHLO wout3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725863AbgIIHHX (ORCPT ); Wed, 9 Sep 2020 03:07:23 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id DF22C9C4; Wed, 9 Sep 2020 03:07:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 09 Sep 2020 03:07:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=D+K42dGY4mJ+XfwGsoIiELdV9Ku H2LhoUP8m42K12q0=; b=E+bYY3r6QX+yb9I01hy8EHSqQsNxxNurRCRw2pF+Pn7 1goELCV6t8+ZnQtaXd3c6c/7Ho1pO8GQAS8Bcq8HkAccnujEcZLlNxEIftJThy1e L5akYi5QqWCq6evphzDHMcGEhNNohWmMo5qHO3z3IpJK1q7KzPjICoBgTjEmoRrE xX/8ZDo4sLANTekydSjMpYosptkHiHYENo8hM7SXs+/AbwJq7/zI3hp4KPcf2XMO X/SOenUaS0m/iHWGV73jdKNNdEGhZ0BuoTEx3M74TS75j474gVboW0OvOUkm0bEm r9+WJFJbMIctFt1eMPIo8f6z3JhVN84xTeYj1mZGQ8Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=D+K42d GY4mJ+XfwGsoIiELdV9KuH2LhoUP8m42K12q0=; b=q9zKpoqqCkKO+6vrfnhXxn tMvRal581RPBIGTMqKsGBdugxmIxt6DOkxhr0MYr9S7P0/o2yrDfQxqYK4GWIvU8 FCK2f/vXuv/ip3mEQEy4qvMiz3g98cv5LtTk9Exp9yWP94dwwPIlmjv8fUKXHhRi yyDB0WHyuqSgkTiWGQ4o8hsefnO9fM0lff0N0B1g2OZzfllb+0BX/B6WXRn6KE3A OvYJ7D87UdzXlFE4+EalFBlY4q6uzweMYyMI8UHg3x4f72PmoQenhDnLlQfiaM/R OmBA0mrx0RrDLFaCRu3mMlUMjKS9L7k8qNU0wxEzat4BA/Uc0vS5rdajEPoCFZ1A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehgedguddulecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepifhrvghg ucfmjfcuoehgrhgvgheskhhrohgrhhdrtghomheqnecuggftrfgrthhtvghrnhepveeuhe ejgfffgfeivddukedvkedtleelleeghfeljeeiueeggeevueduudekvdetnecukfhppeek fedrkeeirdejgedrieegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepghhrvghgsehkrhhorghhrdgtohhm X-ME-Proxy: Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) by mail.messagingengine.com (Postfix) with ESMTPA id AE40F3064882; Wed, 9 Sep 2020 03:07:20 -0400 (EDT) Date: Wed, 9 Sep 2020 09:07:29 +0200 From: Greg KH To: James Bottomley Cc: Jarkko Sakkinen , linux-integrity@vger.kernel.org, Mimi Zohar , linux-api@vger.kernel.org Subject: Re: [PATCH RESEND v4 0/1] add sysfs exports for TPM 2 PCR registers Message-ID: <20200909070729.GD311356@kroah.com> References: <20200906203245.18429-1-James.Bottomley@HansenPartnership.com> <20200907053824.GA279469@kroah.com> <20200907132322.GB106839@linux.intel.com> <1599515528.4232.55.camel@HansenPartnership.com> <20200908054552.GB303404@kroah.com> <20200908180513.GB5390@linux.intel.com> <1599588851.10803.29.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1599588851.10803.29.camel@HansenPartnership.com> Sender: linux-api-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Tue, Sep 08, 2020 at 11:14:11AM -0700, James Bottomley wrote: > On Tue, 2020-09-08 at 21:05 +0300, Jarkko Sakkinen wrote: > > On Tue, Sep 08, 2020 at 07:45:52AM +0200, Greg KH wrote: > > > On Mon, Sep 07, 2020 at 02:52:08PM -0700, James Bottomley wrote: > [...] > > > > I've got to say I think binary attributes are actively evil. I > > > > can see > > > > they're a necessity when there's no good way to represent the > > > > data they > > > > contain, like the bios measurement log or firmware code or a raw > > > > interface like we do for the SMP frame code in libsas. But when > > > > there's a well understood and easy to produce user friendly non- > > > > binary > > > > representation, I think dumping binary is inimical to being a > > > > good API. > > > > > > Agreed. > > > > > > thanks, > > > > > > greg k-h > > > > Looking at the patch, something like /pcrs// > > would be a bit cleaner representation than the current /pcrs- > > /. > > That's actually a technical limitation of using the current attribute > groups API: It's designed to support single level directories in sysfs > (or no directory at all). That's not to say we can't do multi-level > ones, but if we do we have to roll our own machinery for managing the > files rather than relying on the groups API. Agreed, do NOT do multi-level attribute groups please, userspace tools will not handle them well, if at all. > Given that the current groups API does all the nasty lifetime > management that I'd otherwise have to do in the patch, I have a strong > incentive for keeping it, which is why the single /pcrs- > / format. Agreed. thanks, greg k-h