Add path length parameter to
rtems_filesystem_eval_path_start_with_root_and_current() so that users
may pass paths without a '\0' termination.
Update #2558.
Notepads where a feature of RTEMS' tasks that simply functioned in
the same way as POSIX keys or threaded local storage (TLS). They were
introduced well before per task variables, which are also deprecated,
and were barely used in favor of their POSIX alternatives.
In addition to their scarce usage, Notepads took up unnecessary memory.
For each task:
- 16 32-bit integers were allocated.
- A total of 64 bytes per task per thread.
This is especially critical in low memory and safety-critical applications.
They are also defined as uint32_t, and therefore are not guaranteed to
hold a pointer.
Lastly, they are not portable solutions for SMP and uniprocessor systems,
like POSIX keys and TLS.
updates #2493.
Move the storage for the thread queue heads to the threads. Each thread
provides a set of thread queue heads allocated from a dedicated memory
pool. In case a thread blocks on a queue, then it lends its heads to
the queue. In case the thread unblocks, then it takes a free set of
threads from the queue. Since a thread can block on at most one queue
this works. This mechanism is used in FreeBSD. The motivation for this
change is to reduce the memory demands of the synchronization objects.
On a 32-bit uni-processor configuration the Thread_queue_Control size is
now 8 bytes, compared to 64 bytes in RTEMS 4.10 (other changes reduced
the size as well).
This was obsolete and broken based upon recent time keeping changes.
Thie build option was previously enabled by adding
USE_TICKS_FOR_STATISTICS=1 to the configure command line.
This propagated into the code as preprocessor conditionals
using the __RTEMS_USE_TICKS_FOR_STATISTICS__ conditional.
These header files were only used by one BSP and they are
hardware dependent. The hardware dependency always made
them bad candidates for where they were in the tree. But
this fixes that.
Make sure also the size is cache aligned since otherwise we may have
some overlap with the next allocation block. A cache invalidate on this
area would be fatal.