Possibly stupid idea: Maybe OStest needs to become part of the OS and not part of apps?
That is possible but leads to some issues some of which are only cosmetic and some which are semantic.
* If we did that, it would not be an OS test. It would be an OS self test of some kin. * You cannot test application interfaces because the test doesn't like in the application user space. * In most configurations (PROTECTED and KERNEL builds), the OS may not be able to call complex applications interfaces. That interface is through a system call gate which should not be used from inside the OS. I'm not sure what would happen if you had many nested system called. * From a standpoint of test philosophy, I would prefer to see the OS test architecturally separate from OS and to use the actual application interfaces in user mode as is specified by the standards.
NOTE: sched_lock() was documented in the past, but that documentation was removed from the repository and from general access for some reason: https://cwiki.apache.org/confluence/display/NUTTX/User+Guide#schedlock From that page: "Description: This function disables context switching by Disabling addition of new tasks to the ready-to-run task list. The task that calls this function will be the only task that is allowed to run until it either calls sched_unlock (the appropriate number of times) or until it blocks itself." I would suggest to add something like: "Interrupts are not disabled, allowing real-time interrupt response to take place."
That documentation has been removed from repository and is not longer a part of the NuttX documentation set. It is not maintained so no one is going to modify it.
I think it could probably be edited on the Confluence page but why would you bother to do that? No one reads that documentation.
As we learn of and confirm additional ones from other OSes, we can continue to add them. Gradually, over time, I recommend to add such documentation to other interfaces as well. That could help people migrating from other RTOSes to NuttX. The file sched/sched/sched_lock.c contains a rather good explanation IMO:
The description in that document is very old now. It even describes the sched_lock() as creating a critical section. That was true prior to adding support of SMP and perhaps even prior to the renaming to enter_critical_section. Now that old text is very misleading.
That point is that there was a lot of valuable documentation that has been thrown in the shitcan and replaced with superficial how-to documentation. There is no longer technical documentation in the repository for the repository and nothing is maintained.
We have an operating system that is basically undocumented.
