All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
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: Wed, 11 Jun 2014 17:09:40 -0500	[thread overview]
Message-ID: <5398D3A4.9090108@redhat.com> (raw)
In-Reply-To: <20140607134150.GA22076@infradead.org>

On 6/7/14, 8:41 AM, Christoph Hellwig wrote:
> 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.

Ok, so I've sent xfs & extN and I am about to send btrfs.

But I still have the nagging feeling that it would be better to have these
mount-option manpages distributed with the kernel, which is ultimately what
they must match.

So although I've sent them all, I'm still feeling unsure about it.  :)

-Eric

  parent reply	other threads:[~2014-06-11 22:10 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
2014-06-09 14:09             ` Eric Sandeen
2014-06-09 14:22             ` Karel Zak
2014-06-11 22:09             ` Eric Sandeen [this message]
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=5398D3A4.9090108@redhat.com \
    --to=sandeen@redhat.com \
    --cc=guihc.fnst@cn.fujitsu.com \
    --cc=hch@infradead.org \
    --cc=kzak@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.