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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 420A6C433FE for ; Wed, 23 Mar 2022 13:25:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234265AbiCWN0b (ORCPT ); Wed, 23 Mar 2022 09:26:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236642AbiCWN00 (ORCPT ); Wed, 23 Mar 2022 09:26:26 -0400 Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 53E7342A23 for ; Wed, 23 Mar 2022 06:24:53 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id h1so1843391edj.1 for ; Wed, 23 Mar 2022 06:24:53 -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=ofARB/tR+RVoABReGEuRsRQFB51fG8u0uAhot0zbmMw=; b=kiS6nqG1b2tpgSMlBhPduqhTR+uUp0NChTeF3Di3s0Gjmx4bKjIIt1C21Otat+l2Q0 4riiJxQWeItg6q+1D7JmS8q2bknHa18aANAwBErwq0pxH33tw+zQsMdsN8+rKLqNK5mG DSpYL7ceqguq/vwomiRqGOlI+eqIUjjbEr7eU= 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=ofARB/tR+RVoABReGEuRsRQFB51fG8u0uAhot0zbmMw=; b=WtTMUznifpI1AF9nU4quUWZ5fhGnhDlxSLkEUS43xrx7tQmXzzGlALMmbFHS26nvtc ZfdZjd5Lo9CS0ZY/tegw+Rp3R6GeSHbENjZDudW1snXltuxQvNEK4I1ryuS0eW3j2RqP 8vusx24x4+FcjLwXojyarAbIqO7pym/YUOs/UUGPYmgKhCHEcNAKCD6QWErpHrSL7pvt +RNsPlJ2l3bcFxdk7jDlR4OiCKrKmlu7gwipc4hZmL1HGzywQwUgpxHKJNpPfqp/kGRT KjXipYZN7A0C4gWXcnA18iOETOMfi1U+9tr7iDK8K/Am1s1bi6D0R79qwyq+BnG9m3KE 21YA== X-Gm-Message-State: AOAM531fFPKBvX7ByU62d7AfSdP3brCt94Z7y5qnSmgB6uTj5mSty97E 24FEOmxc8b1CJEXreG9HuLftTNF/9Ovie1Ke7EkPXA== X-Google-Smtp-Source: ABdhPJyRgW2FVFPWTwmyfY3ygJgDF0P1WjrCCbHGjTDRam6d8g5Mn8TpLo/cwFgpJpNZHxGt28DfDlUbH73eq61XwZ8= X-Received: by 2002:a05:6402:50cf:b0:418:ee57:ed9 with SMTP id h15-20020a05640250cf00b00418ee570ed9mr34726129edb.37.1648041891743; Wed, 23 Mar 2022 06:24:51 -0700 (PDT) MIME-Version: 1.0 References: <20220322192712.709170-1-mszeredi@redhat.com> <20220323114215.pfrxy2b6vsvqig6a@wittgenstein> In-Reply-To: <20220323114215.pfrxy2b6vsvqig6a@wittgenstein> From: Miklos Szeredi Date: Wed, 23 Mar 2022 14:24:40 +0100 Message-ID: Subject: Re: [RFC PATCH] getvalues(2) prototype To: Christian Brauner Cc: Miklos Szeredi , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Linux API , linux-man , LSM , Karel Zak , Ian Kent , David Howells , Linus Torvalds , Al Viro , Christian Brauner , Amir Goldstein , James Bottomley Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 23 Mar 2022 at 12:43, Christian Brauner wrote: > Yes, we really need a way to query for various fs information. I'm a bit > torn about the details of this interface though. I would really like if > we had interfaces that are really easy to use from userspace comparable > to statx for example. The reason I stated thinking about this is that Amir wanted a per-sb iostat interface and dumped it into /proc/PID/mountstats. And that is definitely not the right way to go about this. So we could add a statfsx() and start filling in new stuff, and that's what Linus suggested. But then we might need to add stuff that is not representable in a flat structure (like for example the stuff that nfs_show_stats does) and that again needs new infrastructure. Another example is task info in /proc. Utilities are doing a crazy number of syscalls to get trivial information. Why don't we have a procx(2) syscall? I guess because lots of that is difficult to represent in a flat structure. Just take the lsof example: tt's doing hundreds of thousands of syscalls on a desktop computer with just a few hundred processes. So I'm trying to look beyond fsinfo and about how we could better retrieve attributes, statistics, small bits and pieces within a unified framework. The ease of use argument does not really come into the picture here, because (unlike stat and friends) most of this info is specialized and will be either consumed by libraries, specialized utilities (util-linux, procos) or with a generic utility application that can query any information about anything that is exported through such an interface. That applies to plain stat(2) as well: most users will not switch to statx() simply because that's too generic. And that's fine, for info as common as struct stat a syscall is warranted. If the info is more specialized, then I think a truly generic interface is a much better choice. > I know having this generic as possible was the > goal but I'm just a bit uneasy with such interfaces. They become > cumbersome to use in userspace. I'm not sure if the data: part for > example should be in this at all. That seems a bit out of place to me. Good point, reduction of scope may help. > Would it be really that bad if we added multiple syscalls for different > types of info? For example, querying mount information could reasonably > be a more focussed separate system call allowing to retrieve detailed > mount propagation info, flags, idmappings and so on. Prior approaches to > solve this in a completely generic way have gotten us not very far too > so I'm a bit worried about this aspect too. And I fear that this will just result in more and more ad-hoc interfaces being added, because a new feature didn't quite fit the old API. You can see the history of this happening all over the place with multiple new syscall versions being added as the old one turns out to be not generic enough. I think a new interface needs to - be uniform (a single utility can be used to retrieve various attributes and statistics, contrast this with e.g. stat(1), getfattr(1), lsattr(1) not to mention various fs specific tools). - have a hierarchical namespace (the unix path lookup is an example of this that stood the test of time) - allow retrieving arbitrary text or binary data And whatever form it takes, I'm sure it will be easier to use than the mess we currently have in various interfaces like the mount or process stats. Thanks, Miklos