From: Willy Tarreau <w@1wt.eu>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-api@vger.kernel.org
Subject: Re: Why is the bit size different between a syscall and its wrapper?
Date: Fri, 12 Mar 2021 04:27:12 +0100 [thread overview]
Message-ID: <20210312032712.GB27924@1wt.eu> (raw)
In-Reply-To: <CAK7LNAQYMKqixm8dVbbMvgt+=MEROSg-JG_kHS8T+xmrgeLABg@mail.gmail.com>
On Fri, Mar 12, 2021 at 11:48:11AM +0900, Masahiro Yamada wrote:
> Hi.
>
> I think I am missing something, but
> is there any particular reason to
> use a different bit size between
> a syscall and its userspace wrapper?
>
>
>
> For example, for the unshare syscall,
>
> unshare(2) says the parameter is int.
>
>
> SYNOPSIS
> #define _GNU_SOURCE
> #include <sched.h>
>
> int unshare(int flags);
>
>
>
>
> In the kernel, it is unsigned long.
>
>
> SYSCALL_DEFINE1(unshare, unsigned long, unshare_flags)
> {
> return ksys_unshare(unshare_flags);
> }
The syscalls must have a well defined interface for a given architecture.
Thus in practice the ABI will define that arg1 goes into this register,
arg2 into this one etc, regardless of their type (plenty of them are
pointers for example). The long is the size of a register so it can carry
any of the types we care about. So by defining each syscall as a function
taking 1 to 6 fixed-size arguments you can implement about all syscalls.
Regarding the libc, it has to offer an interface which is compatible with
the standard definition of the syscalls as defined by POSIX or as commonly
found on other OSes, and this regardless of the platform.
For example look at recv(), it takes an int, a pointer, a size_t and an
int. It requires to be defined like this for portability, but at the OS
level all these will typically be passed as a register each.
Hoping this helps,
Willy
next prev parent reply other threads:[~2021-03-12 3:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-12 2:48 Why is the bit size different between a syscall and its wrapper? Masahiro Yamada
2021-03-12 3:17 ` Bhaskar Chowdhury
2021-03-12 3:27 ` Willy Tarreau [this message]
2021-03-14 5:10 ` Masahiro Yamada
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=20210312032712.GB27924@1wt.eu \
--to=w@1wt.eu \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@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).