casaroli opened a new pull request, #21105:
URL: https://github.com/apache/nuttx/pull/21105

   ## Summary
   
   Two functions that programs of protected and kernel builds could not link, 
one commit each: the System V message queue calls had no system call, and 
posix_madvise() was in the kernel only.
   
   ### msg-syscalls
   
   `msgget()`, `msgctl()`, `msgsnd()` and `msgrcv()` are kernel code 
(`sched/mqueue`), but they are not system calls. In a protected or a kernel 
build, a user program that calls them does not link.
   
   This PR adds them to `syscall/syscall.csv` and 
`include/sys/syscall_lookup.h`, with the condition of their code 
(`CONFIG_DISABLE_MQUEUE_SYSV` not set).
   
   ### libc-posix-madvise
   
   `posix_madvise()` is defined in `fs/mmap/fs_mmisc.c` and has no system call. 
So in protected and kernel builds, a user program that calls it (or 
`madvise()`, which `<sys/mman.h>` maps to it) does not link. The function 
ignores the advice and touches no kernel state, so it does not need a system 
call.
   
   This PR moves the function to `libs/libc/misc` as it is (Make and CMake), 
and adds it to `libc.csv`. Flat builds link the same function from the C 
library instead of `fs/`.
   
   ## Impact
   
   - msg-syscalls: Protected and kernel builds: user programs can use System V 
message queues. The system call numbers after the new entries change (they are 
not a stable ABI). Flat builds: no change. Documentation: no change 
(`Documentation/standards/posix.rst` already lists the four functions as 
supported).
   - libc-posix-madvise: User programs of protected and kernel builds can call 
`posix_madvise()` and `madvise()`. The behavior does not change: the advice is 
ignored and 0 is returned. No new system call. Documentation: no change 
(`Documentation/standards/posix.rst` lists `posix_madvise()` as "Empty", which 
stays true).
   
   ## Testing
   
   The branches were first tested one by one (below). Then all commits of this 
PR together, on master b79dc18e015: msgsys.c, madvise.c on `qemu-armv8a:knsh` 
(QEMU with HVF) all PASS, and ostest exits with status 0 on `qemu-armv8a:knsh` 
and `qemu-armv8a:nsh`.
   
   ### msg-syscalls
   
   Test program `msgsys.c`: `msgget(IPC_PRIVATE)`, `msgsnd()` of one message, 
`msgctl(IPC_STAT)` gives `msg_qnum` 1, `msgrcv()` gives the message, 
`msgrcv(IPC_NOWAIT)` of the empty queue gives -1, `msgctl(IPC_RMID)`, then 
`IPC_STAT` gives `EINVAL`.
   
   | | master | this PR |
   |---|---|---|
   | `msgsys.c` on `qemu-armv8a:knsh` (kernel, arm64, QEMU with HVF) | does not 
link: `msgctl`, `msgget`, `msgrcv`, `msgsnd` undefined | all PASS |
   | ostest, `qemu-armv8a:knsh` and `qemu-armv8a:nsh` | status 0 | status 0 |
   
   Build, each OK (master aeab6fbf989 with this change and other small 
independent fixes): `rv-virt:pnsh64` (protected, rv64), `rv-virt:knsh64` 
(kernel, rv64), `mps2-an500:knsh` (protected, armv7-m), `qemu-armv8a:knsh` with 
`CONFIG_DISABLE_MQUEUE` and `CONFIG_DISABLE_MQUEUE_SYSV`, and 
`qemu-armv8a:knsh` with only `CONFIG_DISABLE_MQUEUE`.
   
   No test in nuttx-apps covers System V message queues.
   
   ### libc-posix-madvise
   
   Test program `madvise.c`: `posix_madvise()` of a heap buffer with each 
`POSIX_MADV_xxx` gives 0; `madvise()` with `MADV_DONTNEED` and `MADV_HUGEPAGE` 
gives 0.
   
   | | master | this PR |
   |---|---|---|
   | `madvise.c` on `qemu-armv8a:knsh` (kernel, arm64, QEMU with HVF) | does 
not link: `posix_madvise` undefined | all PASS |
   | ostest, `qemu-armv8a:knsh` and `qemu-armv8a:nsh` | status 0 | status 0 |
   
   Build, each OK (master aeab6fbf989 with this change and other small 
independent fixes): `rv-virt:pnsh64` (protected, rv64: the user `libc.a` and 
the kernel `libkc.a` define `posix_madvise`), `rv-virt:knsh64` (kernel, rv64), 
`mps2-an500:nsh` (flat, armv7-m), `mps2-an500:knsh` (protected, armv7-m), 
`qemu-armv8a:nsh_smp`, and `qemu-armv8a:nsh` with CMake (only `libc.a` defines 
`posix_madvise`).
   
   `tools/checkpatch.sh -c -u -m -g` passes.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to