From: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
To: Christian Brauner <brauner@kernel.org>,
Michael Kerrisk <mtk.manpages@gmail.com>,
linux-man@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>,
linux-fsdevel@vger.kernel.org,
Christian Brauner <christian.brauner@ubuntu.com>
Subject: Re: [PATCH v3] mount_setattr.2: New manual page documenting the mount_setattr() system call
Date: Sun, 1 Aug 2021 15:47:53 +0200 [thread overview]
Message-ID: <828acf6c-dd06-e153-f7c8-9e1de7342b5f@gmail.com> (raw)
In-Reply-To: <20210731101527.423200-1-brauner@kernel.org>
Hi Christian,
This time I'm going to point out issues about the contents only, not
groff fixes nor even punctuation fixes. I'll fix those myself and CC
you when I do that.
However, if you render the page yourself (man ./mount_setattr.2), you
will probably notice some formatting issues.
Please see some comments below.
Thanks,
Alex
On 7/31/21 12:15 PM, Christian Brauner wrote:
>
> +.SH ERRORS
> +.TP
> +.B EBADF
> +.I dfd
> +is not a valid file descriptor.
> +.TP
> +.B EBADF
> +An invalid file descriptor value was specified in
> +.I userns_fd.
Why a different wording compared to the above? Aren't they the same?
userns_fd is not a valid descriptor.
That would be consistent with the first EBADF, and would keep the
meaning, right?
> +.TP
> +.B EBUSY
> +The caller tried to change the mount to
> +.BR MOUNT_ATTR_RDONLY
> +but the mount had writers.
This is not so clear. I think I understood it, but maybe using language
similar to that of mount(2) is clearer:
EBUSY source cannot be remounted read‐only, because it still holds
files open for writing.
Something like?:
The caller tried to change the mount to MOUNT_ATTR_ONLY but the mount
still has files open for writing
>
> +static const struct option longopts[] = {
> + {"map-mount", required_argument, 0, 'a'},
> + {"recursive", no_argument, 0, 'b'},
> + {"read-only", no_argument, 0, 'c'},
> + {"block-setid", no_argument, 0, 'd'},
> + {"block-devices", no_argument, 0, 'e'},
> + {"block-exec", no_argument, 0, 'f'},
> + {"no-access-time", no_argument, 0, 'g'},
> + { NULL, 0, 0, 0 },
> +};
The third field is an 'int *'
(https://www.gnu.org/software/libc/manual/html_node/Getopt-Long-Options.html).
Please, use NULL instead of 0.
>
> + struct mount_attr *attr = &(struct mount_attr){};
Wow! Interesting usage of compound literals.
I had to check that this has automatic storage duration (I would have
said that it has static s.d., but no).
I'm curious: why use that instead of just?:
struct mount_attr attr = {0};
>
> + if (ret < 0)
> + exit_log("%m - Failed to change mount attributes\en");
Although I typically use myself that same < 0 check,
manual pages typically use == -1 when a function returns -1 on error
(which most syscalls do), and Michael prefers that.
--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/
next prev parent reply other threads:[~2021-08-01 13:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-31 10:15 [PATCH v3] mount_setattr.2: New manual page documenting the mount_setattr() system call Christian Brauner
2021-08-01 13:47 ` Alejandro Colomar (man-pages) [this message]
2021-08-02 7:50 ` Christian Brauner
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=828acf6c-dd06-e153-f7c8-9e1de7342b5f@gmail.com \
--to=alx.manpages@gmail.com \
--cc=brauner@kernel.org \
--cc=christian.brauner@ubuntu.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
/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