GNU/Weeb Mailing List <[email protected]>
 help / color / mirror / Atom feed
From: Ammar Faizi <[email protected]>
To: Jens Axboe <[email protected]>
Cc: Ammar Faizi <[email protected]>,
	Pavel Begunkov <[email protected]>,
	io-uring Mailing List <[email protected]>,
	GNU/Weeb Mailing List <[email protected]>,
	Muhammad Rizki <[email protected]>,
	Alviro Iskandar Setiawan <[email protected]>,
	Gilang Fachrezy <[email protected]>,
	[email protected]
Subject: [RFC PATCH liburing v1 0/2] Fix memset() issue and simplify function naming
Date: Thu, 24 Nov 2022 12:46:14 +0700	[thread overview]
Message-ID: <[email protected]> (raw)

From: Ammar Faizi <[email protected]>

Hi Jens,

On top of "remove useless branches" series. This is an RFC for
liburing nolibc. There are two patches in this series.

## Patch 1: A fix for memset() issue.

liburing has its own memset() in nolibc.c. liburing nolibc can be
linked to apps that use libc. libc has an optimized version of
memset() function. Alviro reports that he found the memset() from
liburing replaces the optimized memset() from libc when he compiled
liburing statically. When we statically link liburing, the linker will
choose the statically linked memset() over the dynamically linked
memset() that the libc provides.

Change the function name to __uring_memset() and define a macro
memset() as:

    #define memset(PTR, C, LEN) __uring_memset(PTR, C, LEN)

when CONFIG_NOLIBC is enabled. This we don't have to touch the
memset() callers.


## Patch 2: Simplify function naming.

Define malloc() and free() as __uring_malloc() and __uring_free() with
macros when CONFIG_NOLIBC is enabled. This way the callers will just
use malloc() and free() instead of uring_malloc() and uring_free().

Signed-off-by: Ammar Faizi <[email protected]>
---

Ammar Faizi (2):
  nolibc: Do not define `memset()` function in liburing
  nolibc: Simplify function naming

 src/lib.h    | 21 +++++----------------
 src/nolibc.c |  2 +-
 src/setup.c  |  6 +++---
 3 files changed, 9 insertions(+), 20 deletions(-)


base-commit: 8fc22e3b3348c0a6384ec926e0b19b6707622e58
prerequisite-patch-id: d74c76e906701902456e2b19f23c100f38f13326
prerequisite-patch-id: bd6f97f77c8f99bd374cde916f97d6223bcbfa33
prerequisite-patch-id: 7c0f399d75e806786b8a7da4d6e23bdb62876710
prerequisite-patch-id: c087dd983f1732fcb9aad8e5b20baf8b9350a935
prerequisite-patch-id: f22f5b7bf9443839ee5bdb5a162c7c7c723a87eb
-- 
Ammar Faizi


             reply	other threads:[~2022-11-24  5:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-24  5:46 Ammar Faizi [this message]
2022-11-24  5:46 ` [RFC PATCH liburing v1 1/2] nolibc: Do not define `memset()` function in liburing Ammar Faizi
2022-11-24  5:46 ` [RFC PATCH liburing v1 2/2] nolibc: Simplify function naming Ammar Faizi
2022-11-25 13:35 ` [RFC PATCH liburing v1 0/2] Fix memset() issue and simplify " Jens Axboe

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] \
    /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