From: Alejandro Colomar <alx+linux-man@kernel.org>
To: Andrey Albershteyn <aalbersh@kernel.org>
Cc: Alejandro Colomar <alx@kernel.org>,
linux-man@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [RFC v1] man/man2/at.2: Add page
Date: Mon, 26 Oct 2026 16:42:46 +0100 [thread overview]
Message-ID: <at90QEmbZ2bLPdTc@debian> (raw)
In-Reply-To: <at9GMQsNivNuE_jH@aalbersh-thinkpadx1carbongen13.rmtcz.csb>
[-- Attachment #1: Type: text/plain, Size: 2400 bytes --]
Hi Andrey,
> Date: 2026-10-26 13:27:16+0100
> From: Andrey Albershteyn <aalbersh@kernel.org>
>
> On 2026-10-23 19:40:37, Alejandro Colomar wrote:
> > This page documents conventions common to several system calls
> > (most of them conventionally named ...at()).
> >
> > Signed-off-by: Alejandro Colomar <alx@kernel.org>
> > ---
> >
> > Hi!
> >
> > We have a lot of repeated documentation about these system calls, and
> > each one has sligght differences, and some syscalls even have actual
> > behavior differences (such as some accepting NULL, other not, and others
> > documenting that not while they most likely accept NULL).
> >
> > This documentation aims to unify the behavior of as many at() syscalls
> > as possible, and document the odd ones explicitly so that differences
> > are known and justified.
> >
> > If you maintain or know of system calls that don't behave as specified
> > in this page, I'm very interested in having a disussion about them.
> >
> > If you know some mistake in this page (for example, I have not yet
> > documented anything about NULL, because I want to have a discussion
> > about it), please also let me know.
> >
> > I'll reply to this email with a copy of the manual page as it looks when
> > formatted, so you don't need to apply the patch to be able to read it.
> >
> >
> > Have a lovely night!
> > Alex
> >
>
> Looks good to me, this should probably be a series including patches
> which update other man pages to reference this. Wouldn't it be
> better to describe differences on the pages itself, for examples,
> for file_attr:
>
> The dirfd, path and flags arguments are described in *at()*,
> with following discrepancy - NULL value could be used for
> path argument meaning empty string.
Agree; I'm working on patching pages to refer to this one.
And also agree: the differences should be stated in each page, and
avoided in the main at(2) page.
However, we should minimize differences. And also, there are
differences that are currently undocumented, and we should discover
them (by asking someone who knows, I guess). Who is the right person to
be CCed on this? Do you know anyone who's been working in at()
functions heavily?
I'll send a v2, with some pages being updated (still incomplete).
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-10-26 15:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 17:40 [RFC v1] man/man2/at.2: Add page Alejandro Colomar
2026-10-23 17:42 ` Alejandro Colomar
2026-10-23 17:45 ` Alejandro Colomar
2026-10-26 12:27 ` Andrey Albershteyn
2026-10-26 15:42 ` Alejandro Colomar [this message]
2026-10-27 8:10 ` Andrey Albershteyn
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=at90QEmbZ2bLPdTc@debian \
--to=alx+linux-man@kernel.org \
--cc=aalbersh@kernel.org \
--cc=alx@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-man@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