Use private naming to avoid conflicts with user applications
In file included from libuv/src/unix/internal.h:25,
from libuv/src/unix/udp.c:23:
libuv/src/uv-common.h:57: warning: "container_of" redefined
57 | #define container_of(ptr, type, member) \
|
In file included from nuttx/include/nuttx/list.h:47,
from nuttx/include/nuttx/tls.h:40,
from nuttx/include/nuttx/sched.h:48,
from nuttx/include/nuttx/arch.h:87,
from nuttx/include/nuttx/userspace.h:35,
from nuttx/include/nuttx/mm/mm.h:30,
from nuttx/include/nuttx/kmalloc.h:34,
from nuttx/include/nuttx/lib/lib.h:31,
from nuttx/include/stdio.h:35,
from apps/system/libuv/libuv/include/uv.h:59,
from libuv/src/unix/udp.c:22:
nuttx/include/nuttx/nuttx.h:48: note: this is the location of the previous definition
48 | #define container_of(ptr, type, member) \
|
Signed-off-by: chao an <anchao@lixiang.com>
When we close a socket fd, it will call get path on sockets.
`close(socket_fd)` -> `file_closelk(filep)` -> `file_fcntl(F_GETPATH)`
It causes a heavy stack load for each socket close operation.
(We have `GETPATH` for sockets to be used for `fdinfo`)
But the socket fds are not intended to be used for file locks.
And so do some other file types, so we may just limit the usage of flock.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
1. fs_epoll: try again when epoll_teardown() return 0
when poll_notify() called larger than twice when epoll_wait() blocked
in the eph->sem, the semcount will be larger than 1 when epoll_wait()
unblocked and will return 0 directly at the next epoll_wait.
So retry to wait the eph->sem again when epoll_teardown return 0.
2. fs_epoll: poll_setup the fd again even this fd got non-expected event
Some poll implementations need call poll_setup again when their internal
states changed (e.g., local socket), so should add the fd to the epoll
teardown list and poll_setup again at the next epoll_wait even this fd
got the user non-expected event.
Signed-off-by: Bowen Wang <wangbowen6@xiaomi.com>
refs: https://man7.org/linux/man-pages/man2/dup.2.html
The two file descriptors do not share file descriptor flags (the
close-on-exec flag). The close-on-exec flag (FD_CLOEXEC; see
fcntl(2)) for the duplicate descriptor is off.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
The memory allocated with strdup and asprintf is done via lib_malloc
so we need to use lib_free to deallocate memory otherwise the assertion
"Free memory from the wrong heap" is hit with flat mode and user separated
heap enabled mode.
Signed-off-by: Petro Karashchenko <petro.karashchenko@gmail.com>
Both the device and the pipe used the FSNODEFLAG_TYPE_DRIVER type before,
and now add an independent pipe type
Signed-off-by: yinshengkai <yinshengkai@xiaomi.com>
If the shm file is removed and a subsequent close, only release shm
object, but inode is leaked. Should decrease refcount to release inode
when unmapped, that matched with refcount increase when mapped.
Another fix that remove the shm file failed.
nsh> rm /var/shm/pts_mmap_1_2_5
nsh: rm: unlink failed: 6
Signed-off-by: fangxinyong <fangxinyong@xiaomi.com>
1. Update all CMakeLists.txt to adapt to new layout
2. Fix cmake build break
3. Update all new file license
4. Fully compatible with current compilation environment(use configure.sh or cmake as you choose)
------------------
How to test
From within nuttx/. Configure:
cmake -B build -DBOARD_CONFIG=sim/nsh -GNinja
cmake -B build -DBOARD_CONFIG=sim:nsh -GNinja
cmake -B build -DBOARD_CONFIG=sabre-6quad/smp -GNinja
cmake -B build -DBOARD_CONFIG=lm3s6965-ek/qemu-flat -GNinja
(or full path in custom board) :
cmake -B build -DBOARD_CONFIG=$PWD/boards/sim/sim/sim/configs/nsh -GNinja
This uses ninja generator (install with sudo apt install ninja-build). To build:
$ cmake --build build
menuconfig:
$ cmake --build build -t menuconfig
--------------------------
2. cmake/build: reformat the cmake style by cmake-format
https://github.com/cheshirekow/cmake_format
$ pip install cmakelang
$ for i in `find -name CMakeLists.txt`;do cmake-format $i -o $i;done
$ for i in `find -name *\.cmake`;do cmake-format $i -o $i;done
Co-authored-by: Matias N <matias@protobits.dev>
Signed-off-by: chao an <anchao@xiaomi.com>
If sendfile() is called with a zero count, it will nevertheless
try to send the data. This is mostly meaningless, it causes
waste of resources, and in some cases delays.
This commit adds special handling for this case, allowing
sendfile to return immediately zero. The new behavior is
in line with the Linux variant of sendfile.
hujun5