From: Mike Rapoport <rppt@kernel.org>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: "Mauro Carvalho Chehab" <mchehab+huawei@kernel.org>,
"Yury Norov" <yury.norov@gmail.com>,
linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
"Alexander A. Klimov" <grandmaster@al2klimov.de>,
"André Almeida" <andrealmeid@collabora.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Arnd Bergmann" <arnd@arndb.de>,
"David Sterba" <dsterba@suse.com>,
"Joe Perches" <joe@perches.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Aleksa Sarai" <cyphar@cyphar.com>
Subject: Re: [PATCH] Documentation: syscalls: add a note about ABI-agnostic types
Date: Wed, 14 Apr 2021 12:46:01 +0300 [thread overview]
Message-ID: <YHa52ddAzcRGOB/m@kernel.org> (raw)
In-Reply-To: <20210414084605.pdlnjkwa3h47jxno@wittgenstein>
On Wed, Apr 14, 2021 at 10:46:05AM +0200, Christian Brauner wrote:
> On Wed, Apr 14, 2021 at 08:14:22AM +0200, Mauro Carvalho Chehab wrote:
> > Em Tue, 13 Apr 2021 21:40:20 -0700
> > Yury Norov <yury.norov@gmail.com> escreveu:
> >
> > > Ping?
> > >
> > > On Fri, Apr 09, 2021 at 01:43:04PM -0700, Yury Norov wrote:
> > > > Recently added memfd_secret() syscall had a flags parameter passed
> > > > as unsigned long, which requires creation of compat entry for it.
> > > > It was possible to change the type of flags to unsigned int and so
> > > > avoid bothering with compat layer.
> > > >
> > > > https://www.spinics.net/lists/linux-mm/msg251550.html
> > > >
> > > > Documentation/process/adding-syscalls.rst doesn't point clearly about
> > > > preference of ABI-agnostic types. This patch adds such notification.
> > > >
> > > > Signed-off-by: Yury Norov <yury.norov@gmail.com>
> > > > ---
> > > > Documentation/process/adding-syscalls.rst | 7 +++++++
> > > > 1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/Documentation/process/adding-syscalls.rst b/Documentation/process/adding-syscalls.rst
> > > > index 9af35f4ec728..46add16edf14 100644
> > > > --- a/Documentation/process/adding-syscalls.rst
> > > > +++ b/Documentation/process/adding-syscalls.rst
> > > > @@ -172,6 +172,13 @@ arguments (i.e. parameter 1, 3, 5), to allow use of contiguous pairs of 32-bit
> > > > registers. (This concern does not apply if the arguments are part of a
> > > > structure that's passed in by pointer.)
> > > >
> > > > +Whenever possible, try to use ABI-agnostic types for passing parameters to
> > > > +a syscall in order to avoid creating compat entry for it. Linux supports two
> > > > +ABI models - ILP32 and LP64.
> >
> > > > + The types like ``void *``, ``long``, ``size_t``,
> > > > +``off_t`` have different size in those ABIs;
> >
> > In the case of pointers, the best is to use __u64. The pointer can then
> > be read on Kernelspace with something like this:
> >
> > static inline void __user *media_get_uptr(__u64 arg)
> > {
> > return (void __user *)(uintptr_t)arg;
> > }
> >
> >
> > > > types like ``char`` and ``int``
> > > > +have the same size and don't require a compat layer support. For flags, it's
> > > > +always better to use ``unsigned int``.
> > > > +
> >
> > I don't think this is true for all compilers on userspace, as the C
> > standard doesn't define how many bits an int/unsigned int has.
> > So, even if this is today's reality, things may change in the future.
> >
> > For instance, I remember we had to replace "int" and "enum" by "__u32"
> > and "long" by "__u64" at the media uAPI in the past, when we start
> > seeing x86_64 Kernels with 32-bits userspace and when cameras started
> > being supported on arm32.
> >
> > We did have some real bugs with "enum", as, on that time, some
> > compilers (gcc, I guess) were optimizing them to have less than
> > 32 bits on certain architectures, when it fits.
>
> Fwiw, Aleksa and I have written extended syscall documentation
> documenting the agreement that we came to in a dedicated session with a
> wide range of kernel folks during Linux Plumbers last year. We simply
> never had time to actually send this series but fwiw here it is. It also
> mentions the use of correct types. If people feel it's worth it I can
> send as a proper series:
Yes, please.
> From 9035258aaa23c5e1bb5bc2242f97221a3e5b9a87 Mon Sep 17 00:00:00 2001
> From: Christian Brauner <christian.brauner@ubuntu.com>
> Date: Fri, 4 Sep 2020 14:27:47 +0200
> Subject: [PATCH 1/6] docs: split extensibility section into two subsections
...
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2021-04-14 9:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-09 20:43 [PATCH] Documentation: syscalls: add a note about ABI-agnostic types Yury Norov
2021-04-14 4:40 ` Yury Norov
2021-04-14 6:14 ` Mauro Carvalho Chehab
2021-04-14 8:46 ` Christian Brauner
2021-04-14 9:46 ` Mike Rapoport [this message]
2021-04-14 13:38 ` Christian Brauner
2021-04-15 19:34 ` Yury Norov
2021-04-14 16:06 ` Yury Norov
2021-04-27 2:24 ` Yury Norov
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=YHa52ddAzcRGOB/m@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andrealmeid@collabora.com \
--cc=arnd@arndb.de \
--cc=christian.brauner@ubuntu.com \
--cc=corbet@lwn.net \
--cc=cyphar@cyphar.com \
--cc=dsterba@suse.com \
--cc=grandmaster@al2klimov.de \
--cc=joe@perches.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab+huawei@kernel.org \
--cc=yury.norov@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 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.