From: Ammar Faizi <[email protected]>
To: Willy Tarreau <[email protected]>
Cc: Shuah Khan <[email protected]>,
"Paul E. McKenney" <[email protected]>,
Gilang Fachrezy <[email protected]>,
VNLX Kernel Department <[email protected]>,
Alviro Iskandar Setiawan <[email protected]>,
Kanna Scarlet <[email protected]>,
Muhammad Rizki <[email protected]>,
GNU/Weeb Mailing List <[email protected]>,
Linux Kernel Mailing List <[email protected]>,
Linux Kselftest Mailing List <[email protected]>
Subject: Re: [RFC PATCH v1 0/8] nolibc signal handling support
Date: Tue, 27 Dec 2022 20:32:57 +0700 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 12/27/22 1:26 PM, Willy Tarreau wrote:
> Yes, and quite frankly I prefer to make that the least complicated.
> Doing just a simple loop in the _start code is trivial. The main
> concern was to store the data. Till now we had an optional .bss
> section, we didn't save environ and errno was optional. But let's
> be honest, while it does allow for writing the smallest programs,
> most programs will have at least one global variable and will get
> this section anyway, so we don't save anything in practice. This
> concern used to be valid when I was making tiny executables when
> running on floppies where each byte mattered, but now that's pointless.
>
> Thus what I'm proposing is to switch to weak symbol definitions for
> errno, environ, and auxv. I did a quick test to make sure that the same
> symbol was properly used when accessed from two units and that's OK, I'm
> seeing the same instance for all of them (which is better than the current
> situation where errno is static, hence per-unit).
Looks good to me.
> Thus now my focus will be on storing these variables where relevant
> for all archs, so that your getauxval() implementation works on top
> of it. It will be much cleaner and will also improve programs' ease
> of implementation and reliability.
Are you going to wire up a patchset for it?
If so, I'll wait for it. When it's already committed, I'll base this
series on top it.
Or I take your series locally then submit your patches and mine in a
single series.
What do you prefer?
--
Ammar Faizi
next prev parent reply other threads:[~2022-12-27 13:32 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-22 3:51 [RFC PATCH v1 0/8] nolibc signal handling support Ammar Faizi
2022-12-22 3:51 ` [RFC PATCH v1 1/8] nolibc/sys: Implement `sigaction(2)` function Ammar Faizi
2022-12-22 3:51 ` [RFC PATCH v1 2/8] nolibc/sys: Implement `signal(2)` function Ammar Faizi
2022-12-22 3:51 ` [RFC PATCH v1 3/8] nolibc/sys: Implement `getpagesize(2)` function Ammar Faizi
2022-12-22 3:51 ` [RFC PATCH v1 4/8] selftests/nolibc: Add `-Wall` and `-Wno-unsed-function` to the CFLAGS Ammar Faizi
2022-12-22 3:51 ` [RFC PATCH v1 5/8] selftests/nolibc: Add `fork(2)` selftest Ammar Faizi
2022-12-22 3:51 ` [RFC PATCH v1 6/8] selftests/nolibc: Add `sigaction(2)` selftest Ammar Faizi
2022-12-22 3:51 ` [RFC PATCH v1 7/8] selftests/nolibc: Add `signal(2)` selftest Ammar Faizi
2022-12-22 3:51 ` [RFC PATCH v1 8/8] selftests/nolibc: Add `getpagesize(2)` selftest Ammar Faizi
2022-12-22 4:34 ` [RFC PATCH v1 0/8] nolibc signal handling support Willy Tarreau
2022-12-22 13:46 ` Ammar Faizi
2022-12-22 14:55 ` Alviro Iskandar Setiawan
2022-12-27 6:26 ` Willy Tarreau
2022-12-27 13:32 ` Ammar Faizi [this message]
2022-12-27 13:36 ` Ammar Faizi
2022-12-27 18:58 ` Willy Tarreau
2022-12-28 12:23 ` Ammar Faizi
2022-12-27 18:49 ` Willy Tarreau
2022-12-28 12:01 ` Ammar Faizi
2022-12-28 13:35 ` Willy Tarreau
2022-12-29 11:41 ` Ammar Faizi
2023-01-03 3:51 ` Alviro Iskandar Setiawan
2023-01-03 3:54 ` Willy Tarreau
2023-01-03 3:59 ` Ammar Faizi
2023-01-08 13:08 ` [PATCH v1 0/3] nolibc auxiliary vector retrieval support Ammar Faizi
2023-01-08 13:08 ` [PATCH v1 1/3] nolibc/stdlib: Implement `getauxval(3)` function Ammar Faizi
2023-01-08 13:08 ` [PATCH v1 2/3] nolibc/sys: Implement `getpagesize(2)` function Ammar Faizi
2023-01-08 13:08 ` [PATCH v1 3/3] selftests/nolibc: Add `getpagesize(2)` selftest Ammar Faizi
2023-01-08 13:10 ` [PATCH v2 0/4] nolibc signal handling support Ammar Faizi
2023-01-08 13:10 ` [PATCH v2 1/4] nolibc/sys: Implement `sigaction(2)` function Ammar Faizi
2023-01-08 13:10 ` [PATCH v2 2/4] nolibc/sys: Implement `signal(2)` function Ammar Faizi
2023-01-08 13:10 ` [PATCH v2 3/4] selftests/nolibc: Add `fork(2)` selftest Ammar Faizi
2023-01-08 13:10 ` [PATCH v2 4/4] selftests/nolibc: Add `sigaction(2)` selftest Ammar Faizi
2023-01-08 13:28 ` [PATCH v2 0/4] nolibc signal handling support Alviro Iskandar Setiawan
2023-01-08 13:31 ` Ammar Faizi
2023-01-08 13:39 ` 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 \
[email protected] \
[email protected] \
[email protected] \
[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