io-uring.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Louvian Lyndal <louvianlyndal@gmail.com>
To: Ammar Faizi <ammar.faizi@students.amikom.ac.id>,
	Jens Axboe <axboe@kernel.dk>,
	Pavel Begunkov <asml.silence@gmail.com>
Cc: io-uring Mailing List <io-uring@vger.kernel.org>,
	Ammar Faizi <ammarfaizi2@gmail.com>
Subject: Re: [PATCHSET v1 RFC liburing 0/6] Implement the kernel style return value
Date: Fri, 1 Oct 2021 13:44:42 +0700	[thread overview]
Message-ID: <89cf843d-be43-4bd6-0e20-4fb04a500512@gmail.com> (raw)
In-Reply-To: <CAGzmLMX5X45jukOgWuT=+FLvh4eq=mRZ54Rgh1J1W2U3f69fPQ@mail.gmail.com>

On 9/29/21 5:16 PM, Ammar Faizi wrote:
> ### 3) How to deal syscalls
>
> We have 3 patches in this series to wrap the syscalls, they are:
>   - Add `liburing_mmap()` and `liburing_munmap()`
>   - Add `liburing_madvise()`
>   - Add `liburing_getrlimit()` and `liburing_setrlimit()`
>
> For `liburing_{munmap,madvise,getrlimit,setrlimit}`, they will return
> negative value of error code if error. They basically just return
> an int, so nothing to worry about.
>
> Special case is for pointer return value like `liburing_mmap()`. In
> this case we take the `include/linux/err.h` file from the Linux kernel
> source tree and use `IS_ERR()`, `PTR_ERR()`, `ERR_PTR()` to deal with
> it.
>
>
> ### 4) How can this help to support no libc environment?
>
> When this kernel style return value gets adapted on liburing, we will
> start working on raw syscall directly written in Assembly (arch
> dependent).
>
> Me (Ammar Faizi) will start kicking the tires from x86-64 arch.
> Hopefully we will get support for other architectures as well.
>
> The example of liburing syscall wrapper may look like this:
>
> ```c
> void *liburing_mmap(void *addr, size_t length, int prot, int flags,
>                     int fd, off_t offset)
> {      
> #ifdef LIBURING_NOLIBC
>         /*
>          * This is when we build without libc.
>          *
>          * Assume __raw_mmap is the syscall written in ASM.
>          *
>          * The return value is directly taken from the syscall
>          * return value.
>          */
>         return __raw_mmap(addr, length, prot, flags, fd, offset);
> #else
>         /*
>          * This is when libc exists.
>          */
>         void *ret;
>
>         ret = mmap(addr, length, prot, flags, fd, offset);
>         if (ret == MAP_FAILED)
>                 ret = ERR_PTR(-errno);
>
>         return ret;
> #endif
> }
> ```

This will add extra call just to wrap the libc. Consider to static
inline them?

For libc they just check the retval, if it's -1 then return -errno. If
they are inlined, they are ideally identical with the previous version.

Besides they are all internal functions. I don't see why should we
pollute global scope with extra wrappers.

Regards,

--
Louvian Lyndal

  reply	other threads:[~2021-10-01  6:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-29 10:16 [PATCHSET v1 RFC liburing 0/6] Implement the kernel style return value Ammar Faizi
2021-09-29 10:16 ` [PATCHSET v1 RFC liburing 1/6] src/syscall: " Ammar Faizi
2021-09-29 10:16 ` [PATCHSET v1 RFC liburing 2/6] Add kernel error header `src/kernel_err.h` Ammar Faizi
2021-09-29 10:16 ` [PATCHSET v1 RFC liburing 3/6] Add `liburing_mmap()` and `liburing_munmap()` Ammar Faizi
2021-09-29 10:16 ` [PATCHSET v1 RFC liburing 4/6] Add `liburing_madvise()` Ammar Faizi
2021-09-29 10:16 ` [PATCHSET v1 RFC liburing 5/6] Add `liburing_getrlimit()` and `liburing_setrlimit()` Ammar Faizi
2021-09-29 10:16 ` [PATCHSET v1 RFC liburing 6/6] src/{queue,register,setup}: Remove `#include <errno.h>` Ammar Faizi
2021-09-29 10:21 ` [PATCHSET v1 RFC liburing 0/6] Implement the kernel style return value Ammar Faizi
2021-10-01  6:44   ` Louvian Lyndal [this message]
2021-10-01  7:36     ` 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=89cf843d-be43-4bd6-0e20-4fb04a500512@gmail.com \
    --to=louvianlyndal@gmail.com \
    --cc=ammar.faizi@students.amikom.ac.id \
    --cc=ammarfaizi2@gmail.com \
    --cc=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=io-uring@vger.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).