From: Willy Tarreau <w@1wt.eu>
To: Joey Pabalinas <joeypabalinas@gmail.com>,
mingo@kernel.org, paulmck@linux.vnet.ibm.com,
rdunlap@infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] rcutorture/nolibc: add a bit of documentation to explain how to use nolibc
Date: Sun, 30 Dec 2018 08:08:46 +0100 [thread overview]
Message-ID: <20181230070846.GA17139@1wt.eu> (raw)
In-Reply-To: <20181229223324.slqx3qjrmzg5g2w2@gmail.com>
On Sat, Dec 29, 2018 at 12:33:24PM -1000, Joey Pabalinas wrote:
> On Sat, Dec 29, 2018 at 07:02:18PM +0100, Willy Tarreau wrote:
> > + * - the lower level is the arch-specific syscall() definition, consisting in
> > + * assembly code in compound expressions. These are called my_syscall0() to
> > + * my_syscall6() depending on the number of arguments. The MIPS
> > + * implementation is limited to 5 arguments. All input arguments are cast
> > + * to a long stored in a register. These expressions always return the
> > + * syscall's return value as a signed long value which is often either a
> > + * pointer or the negated errno value.
> > + *
> > + * - the second level is mostly architecture-independent. It is made of
> > + * static functions called sys_<name>() which rely on my_syscallN()
> > + * depending on the syscall definition. These functions are responsible
> > + * for exposing the appropriate types for the syscall arguments (int,
> > + * pointers, etc) and for setting the appropriate return type (often int).
> > + * A few of them are architecture-specific because the syscalls are not all
> > + * mapped exactly the same among architectures. For example, some archs do
> > + * not implement select() and need pselect6() instead, so the sys_select()
> > + * function will have to abstract this.
> > + *
> > + * - the third level is the libc call definition. It exposes the lower raw
> > + * sys_<name>() calls in a way that looks like what a libc usually does,
> > + * takes care of specific input values, and of setting errno upon error.
> > + * There can be minor variations compared to standard libc calls. For
> > + * example the open() call always takes 3 args here.
>
> Shouldn't these sentences begin with a capitalized "The" for
> consistency?
Not sure since they're just list items. But probably as such they should
end with a semi-colon and not a dot. Anyway, this is minor and likely for
a later update to the file.
> > /* some archs (at least aarch64) don't expose the regular syscalls anymore by
> > * default, either because they have an "_at" replacement, or because there are
> > * more modern alternatives. For now we'd rather still use them.
>
> Also here. Shouldn't this begin with a capitalized "Some"?
Definitely! Same, I won't emit a patch just for this, Paul already queued it.
Thanks!
Willy
next prev parent reply other threads:[~2018-12-30 7:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-29 18:02 [PATCH-v2 0/3] rcutorture: minor nolibc fixes Willy Tarreau
2018-12-29 18:02 ` [PATCH 1/4] rcutorture/nolibc: fix the clobbered registers in the MIPS syscall definition Willy Tarreau
2018-12-29 18:02 ` [PATCH 2/4] rcutorture/nolibc: fix some poor indentation and alignment Willy Tarreau
2018-12-29 22:30 ` Joey Pabalinas
2018-12-31 19:43 ` Paul E. McKenney
2018-12-29 18:02 ` [PATCH 3/4] rcutorture/nolibc: add a bit of documentation to explain how to use nolibc Willy Tarreau
2018-12-29 22:33 ` Joey Pabalinas
2018-12-30 7:08 ` Willy Tarreau [this message]
2018-12-30 7:40 ` Joey Pabalinas
2018-12-31 20:08 ` Paul E. McKenney
2018-12-31 23:56 ` Willy Tarreau
2019-01-01 0:21 ` Joey Pabalinas
2019-01-01 17:57 ` Paul E. McKenney
2018-12-29 22:35 ` Randy Dunlap
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=20181230070846.GA17139@1wt.eu \
--to=w@1wt.eu \
--cc=joeypabalinas@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rdunlap@infradead.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.