From: Mike Frysinger <vapier@gentoo.org>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org, linux-man@vger.kernel.org
Subject: Re: moving filesystem mount options from util-linux to man-pages
Date: Fri, 19 Jan 2018 13:24:42 -0500 [thread overview]
Message-ID: <20180119182442.GL28967@vapier> (raw)
In-Reply-To: <20180119101245.5umnbe6koa22hneh@ws.net.home>
[-- Attachment #1: Type: text/plain, Size: 2100 bytes --]
On 19 Jan 2018 11:12, Karel Zak wrote:
> On Thu, Jan 18, 2018 at 09:36:37PM -0500, Mike Frysinger wrote:
> > the mount(8) man page covers not only the mount command, but also the
> > various file system options that come from the kernel. it seems like
> > the communities have settled on the man-pages project for holding all
> > the userland-facing documentation, it has good practices for tracking
> > features across versions, and updating it is a lot easier/safer (than
> > util-linux) and up-to-date on the web (via man7.org). while looking
> > up some proc/ramfs options, i noticed util-linux was out of date by
> > over 6 years :/.
>
> Please, send patch if you see any obsolete stuff in mount.8.
> Unfortunately kernel guys (usually) don't care...
>
> > imo, it seems like we should move all kernel-specific documentation
> > out of the util-linux project and into man-pages. obviously all the
> > mount command line options and such should remain.
>
> I've talked about it (including LKML) many times in last ten years.
>
> > specifically i'm looking at "FILESYSTEM-SPECIFIC MOUNT OPTIONS":
> > http://man7.org/linux/man-pages/man8/mount.8.html#FILESYSTEM-SPECIFIC_MOUNT_OPTIONS
> >
> > we probably want to leave "FILESYSTEM-INDEPENDENT MOUNT OPTIONS"
> > in util-linux since those are all parsed by util-linux's mount
> > and turned into the MS_xxx bits.
> >
> > thoughts ? mount(2) doesn't seem like the best place, but these
> > are the fields that go in the "data" string to that syscall.
>
> Fortunately, this "move project" is already on the way. The target is
> man section 5 and FS specific packages. We already successfully moved
>
> man nfs
> man xfs
> man ext4 (ext2, ...)
if you're OK with that direction, then that makes sense to me
> All depends on FS maintainers. I'm going to support arbitrary activity
> in this area, but this does not depend on util-linux project.
man-pages is a community project, so i don't think that's entirely
accurate. but i'll just send more deletion updates for util-linux.
-mike
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2018-01-19 18:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-19 2:36 moving filesystem mount options from util-linux to man-pages Mike Frysinger
2018-01-19 10:12 ` Karel Zak
2018-01-19 18:24 ` Mike Frysinger [this message]
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=20180119182442.GL28967@vapier \
--to=vapier@gentoo.org \
--cc=kzak@redhat.com \
--cc=linux-man@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 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).