- Remove per-thread errno from the TCB structure (pterrno)
- Remove get_errno() and set_errno() as functions. The macros are still available as stubs and will be needed in the future if we need to access the errno from a different address environment (KERNEL mode).
- Add errno value to the tls_info_s structure definitions
- Move sched/errno to libs/libc/errno. Replace old TCB access to the errno with TLS access to the errno.
Revert a portion of eca7059785 that
causes compiler warnings about unused variables if nx_start() is not
initializing any of the user-mode heap, kernel-mode heap, or page
allocator:
init/nx_start.c: In function 'nx_start':
init/nx_start.c:552:14: warning: unused variable 'heap_size'
[-Wunused-variable]
size_t heap_size;
^~~~~~~~~
init/nx_start.c:551:17: warning: unused variable 'heap_start'
[-Wunused-variable]
FAR void *heap_start;
^~~~~~~~~~
See dev@nuttx.apache.org mailing list discussion "New unused variables
warning in nx_start()" starting 6 May 2020, archived here:
https://lists.apache.org/thread.html/r3900727e6a06f4445d6eb881d065119ba6647daab89600c3d45d1424%40%3Cdev.nuttx.apache.org%3E
sched/init/nx_start.c:
* If none of MM_KERNEL_USRHEAP_INIT, CONFIG_MM_KERNEL_HEAP, or
CONFIG_MM_PGALLOC are defined, the variables heap_start and
heap_size were declared but never used.
* This change reinstates wrapping the block with a preprocessor
conditional to prevent the variables being declared if they will
not be used. This preprocessor condition was removed in the
above-mentioned commit.
There is a DEBUGPANIC in some logic. This happens if a a task exists at certain points with priority inheritance enabled. This event was not expected in the original design (although logic was provided to support it). Since, apparently, it does happen, the DEBUGPANIC must be removed.
Noted by Brennan Ashton.
The sched_get_stackinfo() interface was just added. However, it occurs to me that it is a dangerous feature and could lead to security problems. In FLAT and PROTECTED modes, if you get access to any other threads stack, you could do harm.
This commit adds some level of security. Basically, it implements these rules:
1. Any thread may query its own stack,
2. A kernel thread may query the stack of any other thread
3. Application threads, however, may query only the stacks of threads within the same task group, i.e., the main thread and any of the child pthreads created with the main thread as a parent or grandparent or great-grandpart ...
The new OS interface, sched_get_stackinfo() combines two pthread-specific interfaces into a single generic interface. The existing pthread_get_stackaddr_np() and pthread_get_stacksize_np() are moved from sched/pthread to libs/libc/pthread.
There are two motivations for this change: First, it reduces the number of system calls. Secondly, it adds a common hook that is going to used for a future implementation of TLS.
Sockets are created in two steps:
1. The socket is allocated, then
2. The socket is initialized.
In SMP mode, there is a possibility that a pthread executing one CPU may create a new task while a pthread on another CPU has allocated the socket but not yet initialized it. This commit updates the socket clone test to assure that the socket is both allocated and initailized.
Without the change, it is possible that uninitialized sockets could be cloned, leading to errors later in the newly started task.
These warnings fix a class of warnings that I saw during CI checks for macOS sim builds. For example:
devif/devif_callback.c:111:49: warning: for loop has empty body [-Wempty-body]
prev = curr, curr = curr->nxtdev);
^
devif/devif_callback.c:111:49: note: put the semicolon on a separate line to silence this warning
I did not put the semi-colon on a separate line, but used braces.
This commit resolves issue #620:
Remove CONFIG_CAN_PASS_STRUCTS #620
The configuration option CONFIG_CAN_PASS_STRUCTS was added many years ago to support an old version of the SDCC compiler. That compiler is currently used only with the Z80 and Z180 targets. The limitation of that old compiler was that it could not pass structures or unions as either inputs or outputs. For example:
#ifdef CONFIG_CAN_PASS_STRUCTS
struct mallinfo mallinfo(void);
#else
int mallinfo(FAR struct mallinfo *info);
#endif
And even leads to violation of a few POSIX interfaces like:
#ifdef CONFIG_CAN_PASS_STRUCTS
int sigqueue(int pid, int signo, union sigval value);
#else
int sigqueue(int pid, int signo, FAR void *sival_ptr);
#endif
This breaks the 1st INVIOLABLES rule:
Strict POSIX compliance
-----------------------
o Strict conformance to the portable standard OS interface as defined at
OpenGroup.org.
o A deeply embedded system requires some special support. Special
support must be minimized.
o The portable interface must never be compromised only for the sake of
expediency.
o Expediency or even improved performance are not justifications for
violation of the strict POSIX interface
Also, it appears that the current SDCC compilers have resolve this issue and so, perhaps, this is no longer a problem: z88dk/z88dk#1132
NOTE: This commit cannot pass the PR checks because it depends on matching changes to the apps/ directory.
Hello,
I am testing priority inversion feauture of Nuttx scheduler. I encounter with problem in tests.
Here is problem:
nxsched_readytorun_setpriority() function not works as expected when DEBUG_ASSERTION not enabled. Because sched_removereadytorun() and sched_addreadytorun() is not called in this case. These functions wrapped with DEBUGASSERT macro and with the effect of DEBUGASSERT macro, sched_removereadytorun() and sched_addreadytorun() not called when DEBUG_ASSERTION not enabled. Therefore priority inversion not works as expected.
Could you check this problem ? Is this a bug, if not what is the purpose of this code ?
Thanks,
Şükrü Bahadır Arslan
A mutex may be configured with rather exotic options such as recursive, unsafe, etc. The availability of these mutex options is controlled by configuation settings. When each option is enabled, additional fields are managed inside of the mutex structure.
pthread_cond_wait() and pthread_timed_wait() do the following atomically: (1) unlock the mutex, (2) wait for the condition, and (3) restore the mutex lock. When that lock is restored, pthread_cond_[timed]wait() must also restore the exact configuration of the mutex data structure if these "exotic" features are enabled.
Now that nxsem_wait_uninterruptible() returns an error when the thread is canceled, new logic is being executed. This revealed an existing error in pthread_cond_wait(). The nature of the error is as follows:
* pthread_cond_wait() must atomically (1) release the mutex, (2) wait on the condition, and (3) re-establish the mutex. Errors can occur on any of these steps. In this case the ECANCELED error was (very correctly) reported by nxsem_wait_uninterruptible().
* However, logic in step (3) had a bug; it re-acquired the mutex, but then a bug in existing logic cause the mutex to be improperly initialized. Essentially, the wrong error status value was being testing. This resulted in a nonsequitar and errors reported by the OS test.
This problem was found by apps/testing/ostest/pthread_cleanup.c
Resolution of Issue 619 will require multiple steps, this part of the first step in that resolution: Every call to nxsem_wait_uninterruptible() must handle the return value from nxsem_wait_uninterruptible properly. This commit is only for those files under graphics/, mm/, net/, sched/, wireless/bluetooth.
Still to do: Files under fs/, drivers/, and arch. The last is 116 files and will take some effort.
nxsem_timedwait_uninterruptible() must return -ECANCELED if the thread is canceled:
include/nuttx/semaphore.h: Return if nxsem_wait() returns ECANCELED meaning that the thread waiting for the semaphore has been canceled.
sched/semaphore/sem_timedwait.c: Same change (the inline version is in semaphore.h, the non-inlined version is in sem_tickwait.c).
drivers/sensors/lps25h.c and drivers/wireless/bluetooth/bt_uart_bcm4343x.c: Make sure that the caller deals correctly with the -ECANCELED return value.
Refer to issue 619.
* The appropriate size of stack varies among archs.
E.g. for 64-bit sim, 2048 is way too small, especially when the task
happens to use host OS functionalities.
I plan to allow an arch provide its own default.
* I plan to use this to replace hardcoded "STACKSIZE = 2048" in APPDIR.
Move the prototype for the internal OS from from sched/sched/sched.h to include/nuttx/sched.h. This was done because binfmt/binfmt/excecmodule.c requires the prototype for sched_releasetcb() and was illegally including sched/sched/sched.h. That is a blatant violation of the OS modular design and the person that did this should be hung up by their thumbs. Oh... I did that back in a bad moment in 2014. Now that is made right.
Update all files possible under sched/timer to Apache 2.0. These excludes two files that have a Xiaomi copyright. Also, run all modified files through nxstyle to assure that the conform to the coding standard.
PR #488 introduced an error in a file license header in file sched/mqueue/mqueue.h. This commit fixe that error and in the course of doing that, changing the license header to the standard Apache 2.0 header. I am the author and copyright hold of all modified files.
Also remove the horrible violation of the architectural rules by adding an include path into net in sched/group/Make.defs. Folks, if you are going to participate in this project, you MUST respect the odule architecture and never, never, never do these things.
commit d07afc934e, "fcntl: add O_CLOEXEC/FD_CLOEXEC support" introduce a compilation error .. a bad file inclusion. That commit added an unnecessary inclusion of "socket/socket.h" which is NOT available in the sched sub-directory. It is only available under the net/ sub-directory.
There is no include path for such and inclusion and there must NEVER be such a include path. Module design forbids including header files between diffent "silos" in the design. Nothing under net/ can ever be available to logic under sched/.
I finally figured out why the ez80 code has gotten so big. It is because people have been put putting big inline functions in header files. That is a violation of the coding standard, since only c89 compatibility is required in all common code. But we have been tolerating inline function it because include/nuttx/compiler.h defines 'inline' to be nothing for C89 compilers.
As a result, static inline functions declared within a C file not so bad; the inline qualifier is ignored, if not supported, but otherwise all is well.
But it is catastrophic in header files. Those static inline functions are included as static functions and implemented in EVERY file that includes those header files, even if the functions are never called. That makes the code base huge!So there is another PR coming to fix some of the worst offenders.
This commit fixes two of the worst offenders I have encountered so far: include/nuttx/sempahore.h and cache.h. But there may be a few other changes needed. Under include/nuttx there are still inline functions thread.h, inclue/nuttx/list.h, mutex.h, tree.h, and include/nuttx/crypto/blake2s.h with no protection for compilers that do not handler the inline qualifier. Otherwise we are clean.
With the changes to these two header files, the size of the z20x build is reduced by about 40%. And incredible size savings.
And remove syslog_init_e because all initialization is later now and we don't
distinguish the initialition phase anymore after ramlog don't need special
initialize.
it doesn't make sense that iob initialization is in up_initialize
but other memory components initialization is called in nx_start
Change-Id: Id43aeaa995f340c5943f59a0067a483ff3ac34a2
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Call xxx_timer_initialize from clock subsystem to make timer ready for use as soon as possiblei and revert the workaround:
commit 0863e771a9
Author: Gregory Nutt <gnutt@nuttx.org>
Date: Fri Apr 26 07:24:57 2019 -0600
Revert "sched/clock/clock_initialize.c: clock_inittime() needs to be done with CONFIG_SCHED_TICKLESS and clock_initialize should skip clock_inittime() for external RTC case since the RTC isn't ready yet."
This reverts commit 2bc709d4b9.
Commit 2bc709d4b9 was intended to handle the case where up_timer_gettime may not start from zero case. However, this change has the side-effect of breaking every implementation of tickless mode: After this change the tickless timer structures are used before they are initialized in clock_inittime(). Initialization happens later when up_initialize is called() when arm_timer_initialize().
Since the tickless mode timer is very special, one solution might be to
1. Rename xxx_timer_initialize to up_timer_initialize
2 Move up_timer_initialize to include/nuttx/arch.h
3. Call it from clock subsystem instead up_initialize
Basically, this change make timer initialization almost same as rtc initialization(up_rtc_initialize).
For now, however, we just need to revert the change.
* include: Introduce elf64.h and elf.h
Added elf64.h for 64bit ELF support and moved common definitions
from elf32.h to elf.h. Also introduced Elf_xxx to be used in
common libraries such as binfmt.
* binfmt, include, modlib, module: Add support for ELF64
Elf_xxx must be used instead of Elf32_xxx to support ELF64.
To use ELF64, CONFIG_ELF_64BIT must be enabled.
* binfmt, modlib: Add support for relocate address
* arch: risc-v: Add include/elf.h
* libs: machine: Add risc-v related files.
NOTE: Currently only supports ELF64
* boards: maix-bit: Add elf and posix_spawn configurations
* boards: maix-bit: Add support for module configuration
