Summary:
1.Add configuration to allocate memory from the specified section
2.Replace all memory operations (kmm_) in the vfs with
fs_heap_. When FS_HEAPSIZE > 0, memory is requested for the file system by specifying a configured heap location. By default (i.e. FS_HEAPSIZE=0) fs_heap_ is equivalent to kmm_
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
Summary:
Implementation in accept4 is special, the requested newsock is saved as filep->priv. This will cause sock_file_close to use fs_heap_free filep->priv during close. When fs_heap is configured, the released memory will not be on fs_heap, causing a crash.
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
The FIOC_FILEPATH ioctl call is required if smartfs is to be used
together with inotify monitoring system. This implements the
call support to smartfs file system. The path to the file has to
be stored in smartfs_ofile_s structure during file open (and is freed
during close) as smartfs currently is not able to obtain the path
knowing only the file node. The full path is concatenated with the file
name and creates the full path needed for inotify to detect whether
the file is on the watchlist.
Signed-off-by: Michal Lenc <michallenc@seznam.cz>
Summary:
When restoring rammap fpos, we check the return value to avoid potential problems caused by no error return if the restore fails.
Signed-off-by: chenrun1 <chenrun1@xiaomi.com>
reason:
1 To improve efficiency, we mimic Linux's behavior where preemption disabling is only applicable to the current CPU and does not affect other CPUs.
2 In the future, we will implement "spinlock+sched_lock", and use it extensively. Under such circumstances, if preemption is still globally disabled, it will seriously impact the scheduling efficiency.
3 We have removed g_cpu_lockset and used irqcount in order to eliminate the dependency of schedlock on critical sections in the future, simplify the logic, and further enhance the performance of sched_lock.
4 We set lockcount to 1 in order to lock scheduling on all CPUs during startup, without the need to provide additional functions to disable scheduling on other CPUs.
5 Cpu1~n must wait for cpu0 to enter the idle state before enabling scheduling because it prevents CPUs1~n from competing with cpu0 for the memory manager mutex, which could cause the cpu0 idle task to enter a wait state and trigger an assert.
size nuttx
before:
text data bss dec hex filename
265396 51057 63646 380099 5ccc3 nuttx
after:
text data bss dec hex filename
265184 51057 63642 379883 5cbeb nuttx
size -216
Configuring NuttX and compile:
$ ./tools/configure.sh -l qemu-armv8a:nsh_smp
$ make
Running with qemu
$ qemu-system-aarch64 -cpu cortex-a53 -smp 4 -nographic \
-machine virt,virtualization=on,gic-version=3 \
-net none -chardev stdio,id=con,mux=on -serial chardev:con \
-mon chardev=con,mode=readline -kernel ./nuttx
Signed-off-by: hujun5 <hujun5@xiaomi.com>
Signed-off-by: dulibo1 <dulibo1@xiaomi.com>
1.call_data->refcount is not remote_cpus;
2.nxsched_smp_call_add enqueue the call_data;
3.maybe nxsched_smp_call_handler is just doing;
4.dequeue the call_data but call_data->refcount is not corret;
5.unpredictability case will occur;
reason:
Currently, if we need to schedule a task to another CPU, we have to completely halt the other CPU,
manipulate the scheduling linked list, and then resume the operation of that CPU. This process is both time-consuming and unnecessary.
During this process, both the current CPU and the target CPU are inevitably subjected to busyloop.
The improved strategy is to simply send a cross-core interrupt to the target CPU.
The current CPU continues to run while the target CPU responds to the interrupt, eliminating the certainty of a busyloop occurring.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
When building a branch like `releases/12.7`, the CI Workflow incorrectly checks out the `master` branch of `nuttx-apps`, instead of `releases/12.7`. This PR fixes a typo in `apps_ref`, to check out the correct branch.
reason:
1In the scenario of active waiting, context switching is inevitable, and we can eliminate redundant judgments.
code size
before
hujun5@hujun5-OptiPlex-7070:~/downloads1/vela_sim/nuttx$ size nuttx
text data bss dec hex filename
262848 49985 63893 376726 5bf96 nuttx
after
hujun5@hujun5-OptiPlex-7070:~/downloads1/vela_sim/nuttx$ size nuttx
text data bss dec hex filename
263324 49985 63893 377202 5c172 nuttx
reduce code size by -476
Configuring NuttX and compile:
$ ./tools/configure.sh -l qemu-armv8a:nsh_smp
$ make
Running with qemu
$ qemu-system-aarch64 -cpu cortex-a53 -smp 4 -nographic \
-machine virt,virtualization=on,gic-version=3 \
-net none -chardev stdio,id=con,mux=on -serial chardev:con \
-mon chardev=con,mode=readline -kernel ./nuttx
Signed-off-by: hujun5 <hujun5@xiaomi.com>
reason:
by doing this we can reduce context switch time,
When we exit from an interrupt handler, we directly use tcb->xcp.regs
before
size nuttx
text data bss dec hex filename
225920 409 30925 257254 3ece6 nuttx
after
text data bss dec hex filename
225604 409 30925 256938 3ebaa nuttx
szie change -316
Signed-off-by: hujun5 <hujun5@xiaomi.com>
during migration from legacy pinout some of the FMC pins were ommited because
their names were identical to the new pinout, which didn't cause a compilation error.
This fixes LCD examples.
Also update incomplete stm32f769i-disco FMC support to avoid this kind of bug in the future
up_interrupt_context indicates that we self inside interrupt/handler mode,
replaced to private function is_nesting_interrupt to make less confused.
Signed-off-by: buxiasen <buxiasen@xiaomi.com>
The case want to determine if a interrupt with higher priority and the
interrupt preemption occurred, but up_interrupt_context indicates that we
self inside interrupt/handler mode. As we previously did not handle the
ramvector interrupt correctly, after update breaked the case. We should
use a more clear private function is_nesting_interrupt.
Signed-off-by: buxiasen <buxiasen@xiaomi.com>
nuttx\libs\libc\misc\lib_bitmap.c(1,1): warning C4819: The file contains a character that cannot
be represented in the current code page (936).
Signed-off-by: chenxiaoyi <chenxiaoyi@xiaomi.com>
The feature depends on ARCH_USE_SEPARATED_SECTION
the different memory area has different access speed and cache
capability, so the arch can custom allocate them based on
section names to achieve performance optimization
test:
sim:elf
sim:sotest
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
We need to record the parent's integer register context upon exception
entry to a separate non-volatile area. Why?
Because xcp.regs can move due to a context switch within the fork() system
call, be it either via interrupt or a synchronization point.
Fix this by adding a "sregs" area where the saved user context is placed.
The critical section within fork() is also unnecessary.
