From: Christoph Hellwig <hch@infradead.org>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Karel Zak <kzak@redhat.com>,
Gui Hecheng <guihc.fnst@cn.fujitsu.com>,
util-linux@vger.kernel.org,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] mount: add btrfs to mount.8
Date: Sat, 7 Jun 2014 06:41:50 -0700 [thread overview]
Message-ID: <20140607134150.GA22076@infradead.org> (raw)
In-Reply-To: <5391E3D0.8050608@redhat.com>
On Fri, Jun 06, 2014 at 10:52:48AM -0500, Eric Sandeen wrote:
> On 6/6/14, 5:03 AM, Karel Zak wrote:
> > On Fri, Jun 06, 2014 at 11:44:28AM +0200, Karel Zak wrote:
> >> I personally have no problem to maintain information about arbitrary
> >> FS in mount.8, the problem are updates. Unfortunately, kernel FS developers
> >> don't care about the man page at all and it's very often not up to date.
> >
> > Hmm.. another possible way would be to create a script for util-linux
> > that will analyze kernel Documentation/filesystems/<fsname>.txt and
> > report changes that is necessary to make to mount.8. It should be
> > relative simple with git. I'll try it..
>
> I like that idea. Maybe <fsname.txt> will need a defined format, though,
> right? Maybe asciidoc?
>
> I've still been meaning (in theory) to produce a mount manpage just for xfs.
> I'm still willing to do that if the above doesn't pan out. I just need
> to get to it. I'd be happy to do it for extN as well.
Autogenerating man pages from an adhoc format sounds like the wrong
approach. I'd much rather have proper man paged for every filesystem.
With those we could also drop all that information from the kernel
Documentation directory, where users won't looks for them anyway.
Eric, if you take care of xfs an extN I'll get started on man pages
for the various "minor" filesystems that don't really have active
maintainers.
Not sure if we should go for mount.<fstype>.8 man pages or just improve
the <fstype>.5 pages, but I think the second one is more obvious.
next prev parent reply other threads:[~2014-06-07 13:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-05 2:05 [PATCH] mount: add btrfs to mount.8 Gui Hecheng
2014-06-05 8:03 ` Karel Zak
2014-06-06 6:32 ` Gui Hecheng
2014-06-06 9:44 ` Karel Zak
2014-06-06 10:02 ` Gui Hecheng
2014-06-06 10:03 ` Karel Zak
2014-06-06 10:03 ` Gui Hecheng
2014-06-06 15:52 ` Eric Sandeen
2014-06-07 13:41 ` Christoph Hellwig [this message]
2014-06-09 14:09 ` Eric Sandeen
2014-06-09 14:22 ` Karel Zak
2014-06-11 22:09 ` Eric Sandeen
2014-06-06 10:17 ` Karel Zak
2014-06-09 6:26 ` Gui Hecheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140607134150.GA22076@infradead.org \
--to=hch@infradead.org \
--cc=guihc.fnst@cn.fujitsu.com \
--cc=kzak@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).