Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Chuck Lever" <chuck.lever@oracle.com>
Cc:     "Jeff Layton" <jlayton@kernel.org>,
        "Lorenzo Bianconi" <lorenzo@kernel.org>, linux-nfs@vger.kernel.org,
        lorenzo.bianconi@redhat.com
Subject: Re: [PATCH] NFSD: add version field to nfsd_rpc_status_show handler
In-reply-to: <ZNJctyaMBVuoT6yz@tissot.1015granger.net>
References: <6431d0ea2295a1e128f83cd76a419dee161e4c44.1691482815.git.lorenzo@kernel.org>,
 <169149440399.32308.1010201101079709026@noble.neil.brown.name>,
 <ZNJCIRjI64YIY+I0@tissot.1015granger.net>,
 <ea598236b2da9f1aa9b587ca797afaa9de5545c7.camel@kernel.org>,
 <ZNJLQIxweTaEsu16@tissot.1015granger.net>,
 <ed02b06f96eeeca4d499583f2bdf31a433921aa1.camel@kernel.org>,
 <ZNJctyaMBVuoT6yz@tissot.1015granger.net>
Date:   Wed, 09 Aug 2023 07:45:06 +1000
Message-id: <169153110624.32308.3596310364486971122@noble.neil.brown.name>
Precedence: bulk

On Wed, 09 Aug 2023, Chuck Lever wrote:
> On Tue, Aug 08, 2023 at 10:20:44AM -0400, Jeff Layton wrote:
> > 
> > It would probably be fairly simple to output well-formed yaml instead.
> > JSON and XML are a bit more of a pain.
> 
> If folks don't mind, I would like more structured output like one of
> these self-documenting formats. (I know I said I didn't care before,
> but I'm beginning to care now ;-)

Lustre, which I am somewhat involved with, uses YAML for various things.
If someone else introduced yaml-producing sysfs files to the kernel
first, that might make the path for lustre smoother :-)

Another option is netlink which lustre is stating to use for
configuration and stats.  It is a self-describing format.  The code
looks verbose, but it is widely used in the kernel and so well supported.

> 
> I'm also wondering if we really ought not add another file under
> /proc, which is essentially obsolete. Would /sys/fs/nfsd/yada be
> better for this facility?

It is only under /proc because that is where it is mounted by default :-)
I think it might be sensible to create a node under /sys where all the
content of the nfsd filesystem also appears.
I'm not keen on /sys/fs/nfsd because nfsd isn't a filesystem, it is a
service.
But the /sys/fs seems to be largely unstructured (/proc v2??) so maybe
putting nfsd there is OK.  We could claim that /proc/fs/nfsd is a
filesystem :-)

> 
> I hesitate to even mention network namespaces...

Please do mention them - I find them too easy to forget about.
/proc/fs/nfsd/ inherits the network namespace from whoever mounts it.
So this can work perfectly.
If we created a mirror in /sys/ we would presumably use the namespace of
the process that opens the file.

Thanks,
NeilBrown