Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp926515iob; Wed, 4 May 2022 10:48:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyg0debyjJm5GCDiGqL2VSzJZFPwu1iH460ojyBnbcgyPW8g3kTKn97vY5RRb1eO37KKug/ X-Received: by 2002:a17:90a:d3d3:b0:1bf:2e8d:3175 with SMTP id d19-20020a17090ad3d300b001bf2e8d3175mr754248pjw.2.1651686530047; Wed, 04 May 2022 10:48:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651686530; cv=none; d=google.com; s=arc-20160816; b=HxHCrpaX8vXMHdRaUOmZ2KoKZgMpRvUtgTm0KI8eInUIs4GADSfPDLabcRSpSRbuCR E8sWUawoYpSxS5DFTdMdn9LY4tpVyJRd8oamEdKfOOrYJIhgotYH4z/CLYIyRKR10645 q2B+6mMEQh67Rb4oMb/yUnPZph4p23oD2YwDqieFvrqF3L0KcN2mB3xZwIfIEZ3+2ssT Rb8Xrh+bPvuexLV+9SVdy5G9qKBm/utTi5OTyBl8PMSeghuiJXmDSQ8Up0cZcgEOviCM 24E9hVTM2FQnu0CWCWICQgpbKnT4/fR1j5Aj5dwPQEZp8iHoRm1F/nJh/R2kck4cYSHs ZS4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=WINxzkR+E7FlYuVjAiuqeb4ZexT1Bye73Wkee4or7Gg=; b=lzXB14DcmGVtcuHQbZfcqObyipZ3z5frEGh+TvGglFV2lU1JqNfYOo+tJYXKTchfO1 uC1b0KRKEp2h56Le6wR7uP9G+Rp+1+LioIpn2mLIAxmXNAlJIbtYLGg2X8EOiMUoR9ac 2XRupCys2wg8la4NNMgKC2TgkEyDFjGA8F6W8/Ec4xBCqp7G6gEnlq8cumFzKrj8f1m/ DiCU3i3q3XFea3l0Vh9lszhUC8+Vob2wciGcSZvLhnjESGxTzJk9U/CaO3m6CZyeCzVO 9802rFW4lRMGDxi8hP+7wQDJPrnKV6NxtIoPgB8BYDsazlYryQ4g3rptwXq3TjGLNUiO v55g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="oSd/lUGq"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u1-20020a17090341c100b0015871e5fcefsi7439692ple.164.2022.05.04.10.48.33; Wed, 04 May 2022 10:48:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="oSd/lUGq"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239932AbiECQ6K (ORCPT + 99 others); Tue, 3 May 2022 12:58:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47800 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239915AbiECQ6H (ORCPT ); Tue, 3 May 2022 12:58:07 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC2053A735; Tue, 3 May 2022 09:54:34 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 04738B81F77; Tue, 3 May 2022 16:54:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7148AC385A4; Tue, 3 May 2022 16:54:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1651596871; bh=ytgntH0O/XbW8+1fR6Md9tL+ex4msLbEc4nV5PiKs1k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oSd/lUGqJGSI3Aru/ScbE5nSf8QCpZOfA+/k9fDh+sazrcp49byG0adp8zTqWNHZM nWXVQgz7KK7l9iJvVMYB6Jmi91ePINmm7iDqLV4ImcFNGDGo6qyLCI3qu4fUE+fPI5 zoeHKmX1CgE9y4LY5N2yzU88o0wPCdxcPymmulSA= Date: Tue, 3 May 2022 18:54:29 +0200 From: Greg KH To: Miklos Szeredi Cc: Amir Goldstein , linux-fsdevel , Dave Chinner , Theodore Ts'o , Karel Zak , Christian Brauner , linux-kernel , Linux API , linux-man , LSM , Ian Kent , David Howells , Linus Torvalds , Al Viro , Christian Brauner , James Bottomley Subject: Re: [RFC PATCH] getting misc stats/attributes via xattr API Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 03, 2022 at 05:04:06PM +0200, Miklos Szeredi wrote: > On Tue, 3 May 2022 at 16:53, Greg KH wrote: > > > > On Tue, May 03, 2022 at 05:39:46PM +0300, Amir Goldstein wrote: > > > > It should be noted that while this API mandates text keys, > > > it does not mandate text values, so for example, sb iostats could be > > > exported as text or as binary struct, or as individual text/binary records or > > > all of the above. > > > > Ugh, no, that would be a total mess. Don't go exporting random binary > > structs depending on the file, that's going to be completely > > unmaintainable. As it is, this is going to be hard enough with random > > text fields. > > > > As for this format, it needs to be required to be documented in > > Documentation/ABI/ for each entry and key type so that we have a chance > > of knowing what is going on and tracking how things are working and > > validating stuff. > > My preference would be a single text value for each key. Yes! That's the only sane way to maintain apis, and is why we do that for sysfs. If the key isn't present, there's no value, so userspace "knows" this automatically and parsing this is trivial. > Contents of ":mnt:info" contradicts that, but mountinfo has a long > established, well documented format, and nothing prevents exporting > individual attributes with separate names as well (the getvalues(2) > patch did exactly that). I understand, for "legacy" things like this, that's fine, but don't add new fields or change them over time please, that way just gets us back to the nightmare of preserving /proc/ file apis. thanks, greg k-h