public inbox for [email protected]
 help / color / mirror / Atom feed
From: Ammar Faizi <[email protected]>
To: Jens Axboe <[email protected]>,
	Pavel Begunkov <[email protected]>,
	io-uring Mailing List <[email protected]>
Cc: Bedirhan KURT <[email protected]>,
	Louvian Lyndal <[email protected]>,
	Ammar Faizi <[email protected]>
Subject: Re: [PATCHSET v1 RFC liburing 0/6] Add no libc support for x86-64 arch
Date: Thu,  7 Oct 2021 05:20:30 +0700	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On Thu, Oct 7, 2021 at 1:48 AM Jens Axboe <[email protected]> wrote:
>On 10/6/21 8:49 AM, Ammar Faizi wrote:
>> Hi everyone,
>> 
>> This is the v1 of RFC to support build liburing without libc.
>> 
>> In this RFC, I introduce no libc support for x86-64 arch. Hopefully,
>> one day we can get support for other architectures as well.
>> 
>> Motivation:
>> Currently liburing depends on libc. We want to make liburing can be
>> built without libc.
>> 
>> This idea firstly posted as an issue on the liburing GitHub
>> repository here: https://github.com/axboe/liburing/issues/443
>> 
>> The subject of the issue is: "An option to use liburing without libc?".
>
>This series seems to be somewhat upside down. You should fix up tests
>first, then add support for x86-64 nolibc, then enable it. You seem to
>be doing the opposite?
>
>-- 
>Jens Axboe

Yes, that's what I am doing.

I agree with add support for x86-64 nolibc, then enable it. However,
the tests fixes happened very naturally.

I would not be able to caught those broken tests if I didn't add the
nolibc support.

There are two main problems with the tests, all of them are caught
after adding no libc support.

  1) The test uses `errno` to check error from liburing functions,
     this is only problematic with no libc build. I wouldn't be able
     to caught this without adding no libc support. I caught several
     tests failed after added no libc support, then investigated the
     failure causes and found the culprit (it's errno from the libc).

  2) The test uses `free()` to free the return value of
     `io_uring_get_probe{,_ring}` functions
     from liburing. This causes invalid free only for nolibc build.
     So it does really make sense to add no libc support first, then
     fix up the tests. Because there is no way I can know this broken
     situation earlier.

Since now I know everything about the situation, I can do so. So I
will send the RFC v2 and rebase everything based on your order.

Thanks for the comment.

-- 
Ammar Faizi

  reply	other threads:[~2021-10-06 22:21 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-06 14:49 [PATCHSET v1 RFC liburing 0/6] Add no libc support for x86-64 arch Ammar Faizi
2021-10-06 14:49 ` [PATCH v1 RFC liburing 1/6] configure: Add LIBURING_NOLIBC variable Ammar Faizi
2021-10-06 14:49 ` [PATCH v1 RFC liburing 2/6] Add no libc support Ammar Faizi
2021-10-06 14:49 ` [PATCH v1 RFC liburing 3/6] Add x86-64 no libc build support Ammar Faizi
2021-10-06 14:49 ` [PATCH v1 RFC liburing 4/6] test/cq-size: Don't use `errno` to check liburing's functions Ammar Faizi
2021-10-06 14:49 ` [PATCH v1 RFC liburing 5/6] test/{iopoll,read-write}: Use `io_uring_free_probe()` instead of `free()` Ammar Faizi
2021-10-06 14:49 ` [PATCH v1 RFC liburing 6/6] src/{queue,register,setup}: Clean up unused includes Ammar Faizi
2021-10-06 18:47 ` [PATCHSET v1 RFC liburing 0/6] Add no libc support for x86-64 arch Jens Axboe
2021-10-06 22:20   ` Ammar Faizi [this message]
2021-10-06 22:23     ` Jens Axboe
2021-10-07  6:31       ` [PATCHSET v2 RFC liburing 0/5] " Ammar Faizi
2021-10-07  6:31         ` [PATCH v2 RFC liburing 1/5] test/{iopoll,read-write}: Use `io_uring_free_probe()` instead of `free()` Ammar Faizi
2021-10-07 12:25           ` Jens Axboe
2021-10-07  6:31         ` [PATCH v2 RFC liburing 2/5] test/cq-size: Don't use `errno` to check liburing's functions Ammar Faizi
2021-10-07 12:25           ` Jens Axboe
2021-10-07  6:31         ` [PATCH v2 RFC liburing 3/5] Add arch dependent directory and files Ammar Faizi
2021-10-07  6:31         ` [PATCH v2 RFC liburing 4/5] Add no libc build support Ammar Faizi
2021-10-07 12:27           ` Jens Axboe
2021-10-07 13:01             ` Ammar Faizi
2021-10-07  6:31         ` [PATCH v2 RFC liburing 5/5] Add LIBURING_NOLIBC variable and edit src/Makefile Ammar Faizi
2021-10-07 15:02         ` [PATCHSET liburing 0/4] Add no libc support for x86-64 arch Ammar Faizi
2021-10-07 15:02           ` [PATCH liburing 1/4] test/thread-exit: Fix use after free bug Ammar Faizi
2021-10-07 15:02           ` [PATCH liburing 2/4] Add arch dependent directory and files Ammar Faizi
2021-10-07 15:02           ` [PATCH liburing 3/4] Add no libc build support Ammar Faizi
2021-10-07 15:02           ` [PATCH liburing 4/4] Add LIBURING_NOLIBC variable and edit src/Makefile 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=20211006222030.1208080-1-ammar.faizi@students.amikom.ac.id \
    [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