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
