Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp6252644iob; Tue, 10 May 2022 14:02:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwf95QWZO89B9ZzpGgkhIYHTDs4LerSdWtujsnB+lIB/rwkoNdMPiQDGhUdUxC6p3Y4OPIZ X-Received: by 2002:a17:906:478f:b0:6f3:d0b7:b254 with SMTP id cw15-20020a170906478f00b006f3d0b7b254mr21240236ejc.562.1652216571109; Tue, 10 May 2022 14:02:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652216571; cv=none; d=google.com; s=arc-20160816; b=afpFRIJvZHXJLKMd3dBxmWzZ1brDSkXjHHuWD9hcnimQ3yJtXOWBgRf2vn+3Actphc s6HUjNVQGBrOBuQ9STKf/4PXQd6919agozt3Ntiz7unP00PGqwR6miOcLtwQCSJzv46W v7hS+sta28ZStj0Eg9Xy9CqbsMitV7qD9w91jHVZSGCJtGEocE2Raq9H1sR76Kw9KPuC lT2ptHBXdaaVJ4c33I1nuavrWqGJEWVLH3NI50LxzMtzZw8BxtPT389lL41NxV9o5HpS cJiy34wGjxi4QrK/J7/fMVbms+2pTL9tLiPv2KnDuBrrHSofXUiYTAucjC2YTxLTjAqV 1I+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=cEMXxfbHgL5k8G+nQx9Id44d10sZKLXr0DUGje9AXRs=; b=ZsxM+hzV++WFaWpRmRERqn60cwVfJqFAWKforfTs5ZVXWZ/OBuTvY86QVZCcMixb9J wwhxlOqgkMKUicT0rCXIuDbNEckFlnDlyoPTpozdO5PK5pC2o3Oya3i3WRtoHSmAXjb1 yobe1AeIG1pFC1+CUBHGndcGCJOeX9MxAB4TJgwEyTr1Ct7F181Zhbp6J7j6ORAarY6z cDpYgxjThEXgCs5DtFsKu2rtOZ54cpdd7IbsIeZ2ra675M6Nf3YqZ7alK0on/gw3VLKj SuM9r2YDFtctelScsDp8YIoPyBm2+6vBUo9wipQ4jcVWkpgnnujiYqQ9+j0E7+j6HB6X hLtg== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=ANNKvFre; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g15-20020a50ec0f000000b00425f2e6bef2si272771edr.242.2022.05.10.14.02.26; Tue, 10 May 2022 14:02:51 -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=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=ANNKvFre; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240859AbiEJNZA (ORCPT + 99 others); Tue, 10 May 2022 09:25:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45946 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243241AbiEJNVl (ORCPT ); Tue, 10 May 2022 09:21:41 -0400 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5EAD65B3DB for ; Tue, 10 May 2022 06:15:22 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id g23so19955818edy.13 for ; Tue, 10 May 2022 06:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cEMXxfbHgL5k8G+nQx9Id44d10sZKLXr0DUGje9AXRs=; b=ANNKvFreFEu9sBWYzQhnMMLOHwEQYbyIk1iuCaMTgX4k9jEZW/e7PzAnlL8A7orHrh RGh9btUIUpjvRB4tNDpYgwJlTjOL5w6g2oROzijDZBuwqgiqXjt3dJQfSWysmAukJE3W 6fviCca3i7WKiW/KEEtORZFD0aDK8BvFwa/DY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cEMXxfbHgL5k8G+nQx9Id44d10sZKLXr0DUGje9AXRs=; b=rUhYwmFc/+RKI1sMdTIkZLCmG47lKq4r1uixaGyfFPuIByWUllrgD7eQbXm+65jC92 ixSc38uCmv+0UoHH2b6a9WRhoOzIGLOW3f4pG8nboPd09tCReWLBe3ETBKk9xN+Ce/fH xz7WkZ2TS1pVlWgYm8P7sGWVVktuwHaafkNAucBS3gvnkjQx/nwjqB1CbwSrlq3YK8XJ sfZFVD1ZHnCJTHuMVOqb2sbvp/MecBJdCQ9oW7b5vfZuediUcxW5XQf4E5P48yoJ8ow0 jcf2ex8AcOZnxAHJKf42Kc7FPBpfVN02HXrC8QgSQrm3ngtT9rZDutX+WKJM1SoIppYI ++4Q== X-Gm-Message-State: AOAM532htQtqUx/Lvv6cCwRKvnrufJY7F/izU7xAncROwwJGG7YE3bMl pm59DVY5enDgaCSR3QSL/9lYtYIJToSV/G9Jk0/zXA== X-Received: by 2002:a05:6402:50d1:b0:428:1473:d173 with SMTP id h17-20020a05640250d100b004281473d173mr22738467edb.37.1652188517024; Tue, 10 May 2022 06:15:17 -0700 (PDT) MIME-Version: 1.0 References: <20220509124815.vb7d2xj5idhb2wq6@wittgenstein> <20220510115316.acr6gl5ayqszada6@wittgenstein> In-Reply-To: <20220510115316.acr6gl5ayqszada6@wittgenstein> From: Miklos Szeredi Date: Tue, 10 May 2022 15:15:05 +0200 Message-ID: Subject: Re: [RFC PATCH] getting misc stats/attributes via xattr API To: Christian Brauner Cc: linux-fsdevel@vger.kernel.org, Dave Chinner , "Theodore Ts'o" , Karel Zak , Greg KH , linux-kernel@vger.kernel.org, Linux API , linux-man , LSM , Ian Kent , David Howells , Linus Torvalds , Al Viro , Christian Brauner , Amir Goldstein , James Bottomley Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=no 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, 10 May 2022 at 13:53, Christian Brauner wrote: > > What exactly are the attributes that systemd requires? > > We keep a repo with ideas for (kernel) extensions - we should probably > publish that somewhere - but the list we used for a prototype roughly > contains: > > * mount flags MOUNT_ATTR_RDONLY etc. > * time flags MOUNT_ATTR_RELATIME etc. (could probably be combined with > mount flags. We missed the opportunity to make them proper enums > separate from other mount flags imho.) > * propagation "flags" (MS_SHARED) > * peer group > * mnt_id of the mount > * mnt_id of the mount's parent > * owning userns Sounds good thus far. And hey, we don't even need a new syscall: statx(2) could handle these fine. > There's a bit more advanced stuff systemd would really want but which I > think is misplaced in a mountinfo system call including: > * list of primary and auxiliary block device major/minor It's when you need to return variable size arrays or list of strings that the statx kind of interface falls down. For that a hierarchical namespace is a much better choice, as it can represent arbitrary levels of arrays, while doing that with a specialized syscall is going to be cumbersome. > I just have a really hard time understanding how this belongs into the > (f)getxattr() system call family and why it would be a big deal to just > make this a separate system call. Fragmenting syntactically equivalent interfaces is bad, unifying them is good. Dave's example of adding a new syscall for retrieving multiple xattrs is a prime example. Thanks, Miklos