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 86340C433FE for ; Wed, 23 Mar 2022 15:23:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240528AbiCWPZY (ORCPT ); Wed, 23 Mar 2022 11:25:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45018 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245115AbiCWPZS (ORCPT ); Wed, 23 Mar 2022 11:25:18 -0400 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D85806E2BF for ; Wed, 23 Mar 2022 08:23:47 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id qx21so3491115ejb.13 for ; Wed, 23 Mar 2022 08:23:47 -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=mlS/fdRq6hH9/s3MjXNnayc2lVeeN15N6DspmLurFGc=; b=jNl4Povv1P5H6dTnpwFVsSxe3b46c3nud3i9Aj/69tJIIyEVuLAlkNlWc+scUTvntB uXj4WCJwCKQDrvi5WHHpsfydkbN38SdEHthpMbgM0jdgl/C1GDFTt3UhWR/6Kfa1J9Am rlyx19X9S2SwlH7Uq3aWcksl9m15lSuh6UoLQ= 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=mlS/fdRq6hH9/s3MjXNnayc2lVeeN15N6DspmLurFGc=; b=MuWBmGj/tjV45Xt2yIxo5gtGcJ3LTelx6Ln9IRYD2xzpKfpEzJkxpm0rqB6uCV3EH6 RPyVCKSUaN8FVpGGjMW2CPgVOfBPdBRYLBOKejLvaUUuZPurNRIVd279CAgWkDzsstj+ Jq82bAJR024AHUb2w4QDLai2RcInHnd49zN/5YdyRsxq74hDESKWIDnX2iNuZiqrnlQX i3mE8T9SxuYFXEInE8QNbd73hkf/rGJoMrI+ri8Dqi2qa6yTdvw9cf3sM0BfpTeW08bt 1lntj80VxMy4vnoevi59l+oKjafYPhdT4aUddP6rSCs1+UhNcrZ1sJByoEn8RqWn7NO5 KyJg== X-Gm-Message-State: AOAM533ftPECMm2WtboMQEOptR4seHPdEaMgJhBCXsKkJ8O6MM+Epzo9 v87rFnDnwAlfEeh4aZPOMZHP8QSqeizULmaT9oMyCw== X-Google-Smtp-Source: ABdhPJynCIbGxWaH8VNgO7K5SrWmTQgikKoqtYUaFhM+Y0JZe0+LMfjLZkQj57fx03puzkf/rf2QsmRsUGBWm5AVktQ= X-Received: by 2002:a17:906:c259:b0:6ce:a165:cd0d with SMTP id bl25-20020a170906c25900b006cea165cd0dmr546068ejb.270.1648049026221; Wed, 23 Mar 2022 08:23:46 -0700 (PDT) MIME-Version: 1.0 References: <20220322192712.709170-1-mszeredi@redhat.com> <20220323114215.pfrxy2b6vsvqig6a@wittgenstein> In-Reply-To: From: Miklos Szeredi Date: Wed, 23 Mar 2022 16:23:34 +0100 Message-ID: Subject: Re: [RFC PATCH] getvalues(2) prototype To: Greg KH Cc: Christian Brauner , 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 14:38, Greg KH wrote: > This has been proposed in the past a few times. Most recently by the > KVM developers, which tried to create a "generic" api, but ended up just > making something to work for KVM as they got tired of people ignoring > their more intrusive patch sets. See virt/kvm/binary_stats.c for what > they ended up with, and perhaps you can just use that same type of > interface here as well? So this looks like a fixed set of statistics where each one has a descriptor (a name, size, offset, flags, ...) that tells about the piece of data to be exported. The stats are kept up to date in kernel memory and copied to userspace on read. The copy can be selective, since the read can specify the offset and size of data it would like to retrieve. The interface is self descriptive and selective, but its structure is fixed for a specific object type, there's no way this could be extended to look up things like extended attributes. Maybe that's not a problem, but the lack of a hierarchical namespace could turn out to be a major drawback. I think people underestimate the usefulness of hierarchical namespaces, even though we use them extensively in lots of well established interfaces. Thanks, Miklos