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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 85D98C433E0 for ; Wed, 5 Aug 2020 19:26:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 47DD4206F6 for ; Wed, 5 Aug 2020 19:26:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="IRftECyn" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728974AbgHET0P (ORCPT ); Wed, 5 Aug 2020 15:26:15 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:59805 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728687AbgHEROC (ORCPT ); Wed, 5 Aug 2020 13:14:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1596647641; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yTnFp3FGNnUMIV+drG+EiP28NPY1kzNtc5gU15VKTgg=; b=IRftECynq87jUiSLcCluSeDUigQgevfSUIo+31YFvyNWw7GnRHKSlxJX9Rgcgob9LAPp8y tDwIVkeO/inoizwk/LsywieN9mWYkLHc+ihG3R+Rh40+ICBvLsEJVoiyWPdf94DJG1bTM/ 3qJrLHjmS6LLj27dPcMgDAIAFwfSdDQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-404-CVKT19CpOAaHFqv9tWctXA-1; Wed, 05 Aug 2020 13:13:57 -0400 X-MC-Unique: CVKT19CpOAaHFqv9tWctXA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3CC2D80183C; Wed, 5 Aug 2020 17:13:55 +0000 (UTC) Received: from warthog.procyon.org.uk (ovpn-112-32.rdu2.redhat.com [10.10.112.32]) by smtp.corp.redhat.com (Postfix) with ESMTP id 089C25D9DC; Wed, 5 Aug 2020 17:13:48 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <1596555579.10158.23.camel@HansenPartnership.com> References: <1596555579.10158.23.camel@HansenPartnership.com> <159646178122.1784947.11705396571718464082.stgit@warthog.procyon.org.uk> To: James Bottomley Cc: dhowells@redhat.com, viro@zeniv.linux.org.uk, Theodore Ts'o , Andreas Dilger , Eric Biggers , Jeff Layton , linux-ext4@vger.kernel.org, Carlos Maiolino , "Darrick J. Wong" , linux-api@vger.kernel.org, torvalds@linux-foundation.org, raven@themaw.net, mszeredi@redhat.com, christian@brauner.io, jannh@google.com, kzak@redhat.com, jlayton@redhat.com, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/18] VFS: Filesystem information [ver #21] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2329128.1596647628.1@warthog.procyon.org.uk> Date: Wed, 05 Aug 2020 18:13:48 +0100 Message-ID: <2329129.1596647628@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org James Bottomley wrote: > It sort of petered out into a long winding thread about why not use > sysfs instead, which really doesn't look like a good idea to me. It seemed to turn into a set of procfs symlinks that pointed at a bunch of sysfs stuff - or possibly some special filesystem. > Could I make a suggestion about how this should be done in a way that > doesn't actually require the fsinfo syscall at all: it could just be > done with fsconfig. I'd prefer to keep it separate. The interface for fsconfig() is intended to move stuff into the kernel, not out of it. Better to add a parallel syscall to go the other way (kind of like we have setxattr/getxattr, sendmsg/recvmsg). Further, fsinfo() can refer directly to a file/fd/mount/whatever, but fsconfig() doesn't do that. You have to use fspick() to get a context before you can use fsconfig(). Now, that's fine if you want to gather several pieces of information from a particular object, but it's not so good if you want to get one piece of information from each of several objects. > ... make it table configured... I did, kind of (though I didn't call it that). Al rewrote the code to get rid of it. David