From: Alviro Iskandar Setiawan <[email protected]>
To: Ammar Faizi <[email protected]>
Cc: Willy Tarreau <[email protected]>, Shuah Khan <[email protected]>,
"Paul E. McKenney" <[email protected]>,
Gilang Fachrezy <[email protected]>,
"GNU/Weeb Mailing List" <[email protected]>,
VNLX Kernel Department <[email protected]>,
Linux Kernel Mailing List <[email protected]>,
Linux Kselftest Mailing List <[email protected]>
Subject: Re: [PATCH v3 0/5] nolibc signal handling support
Date: Mon, 16 Jan 2023 00:06:44 +0700 [thread overview]
Message-ID: <CAOG64qMcvd==jfHc22q2=n79siixqbKOxb7N8i6SXjqCJtnZpw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
On Sun, Jan 15, 2023 at 11:01 PM Ammar Faizi wrote:
> That is not the 'sigset_t' that the kernel wants. The kernel wants the
> 'sigset_t' that is in <asm-generic/signal.h>:
>
> #define _NSIG 64
> #define _NSIG_BPW __BITS_PER_LONG // this 64 on x86-64, but 32 on i386.
> #define _NSIG_WORDS (_NSIG / _NSIG_BPW)
>
> typedef struct {
> unsigned long sig[_NSIG_WORDS];
> } sigset_t;
>
> The above struct is always 8 bytes in size. In other words:
>
> _NSIG_WORDS == 2 on i386
> _NSIG_WORDS == 1 on x86-64
> sizeof(unsigned long) == 4 on i386
> sizeof(unsigned long) == 8 on x86-64
>
> Therefore, sizeof(unsigned long [_NSIG_WORDS]) is always 8 on both
> architectures. That's the correct size.
>
> I tried to #include <asm-generic/signal.h> but it conflicts with the
> other 'sigset_t' definition. So I can't do that.
Read the glibc sigaction implementation, it has different struct
sigaction definitions for user and kernel too.
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/libc_sigaction.c;h=3cbf241a5fa28296c910fa40a41b09d2b6113b05;hb=7e31d166510ac4adbf53d5e8144c709a37dd8c7a
Since nolibc compiles everything in a single translation unit, you
can't have a different sigset_t definition. You need to copy the
definition to nolibc header and change the type name to something else
for internal use only.
> Why are there two different definitions of 'sigset_t'? I don't know.
>
> I probably should read the story behind this syscall to get it
> implemented right. Let me ponder this again on Monday. But at least I
> tell what I have found so people can give some comments on it...
`man 2 rt_sigaction` tells the story. Here is the bedtime story, have
a nice dream :-)
The original Linux system call was named sigaction(). However, with
the addition of real-time signals in Linux 2.2, the fixed-size, 32-bit
sigset_t type supported by that system call was no longer fit for
purpose.
Consequently, a new system call, rt_sigaction(), was added to support
an enlarged sigset_t type. The new system call takes a fourth
argument, size_t sigsetsize, which specifies the size in bytes of the
signal sets
in act.sa_mask and oldact.sa_mask. This argument is currently required
to have the value sizeof(sigset_t) (or the error EINVAL results). The
glibc sigaction() wrapper function hides these details from us,
transpar‐
ently calling rt_sigaction() when the kernel provides it.
next prev parent reply other threads:[~2023-01-15 17:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-08 13:58 [PATCH v3 0/5] nolibc signal handling support Ammar Faizi
2023-01-08 13:59 ` [PATCH v3 1/5] nolibc/sys: Implement `sigaction(2)` function Ammar Faizi
2023-01-08 13:59 ` [PATCH v3 2/5] nolibc/sys: Implement `signal(2)` function Ammar Faizi
2023-01-08 13:59 ` [PATCH v3 3/5] selftests/nolibc: Add `fork(2)` selftest Ammar Faizi
2023-01-08 13:59 ` [PATCH v3 4/5] selftests/nolibc: Add `sigaction(2)` selftest Ammar Faizi
2023-01-08 13:59 ` [PATCH v3 5/5] selftests/nolibc: Add `signal(2)` selftest Ammar Faizi
2023-01-08 17:58 ` [PATCH v3 0/5] nolibc signal handling support Willy Tarreau
2023-01-08 18:31 ` Ammar Faizi
2023-01-08 18:49 ` Willy Tarreau
2023-01-15 16:01 ` Ammar Faizi
2023-01-15 17:06 ` Alviro Iskandar Setiawan [this message]
2023-01-17 23:17 ` Ammar Faizi
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='CAOG64qMcvd==jfHc22q2=n79siixqbKOxb7N8i6SXjqCJtnZpw@mail.gmail.com' \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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