The first pass at building these was without networking enabled.
This pass addresses that plus accounts for some new BSPs which
needed testsuite.tcfg files and BSPs which could not link tests
which had been added since the first pass.
When a thread is removed from a thread queue or is unblocked
by receiving an event, the same actions are required.
+ timeout watchdog canceled,
+ thread must be unblocked, and
+ (MP only) proxy cleaned up
This patch makes sure there is only one copy of this code.
There was a lot of duplication between the discipline subroutines.
With the transition to RBTrees for priority discipline, there were
only a few lines of source code manipulating the data structure
for FIFO and priority. Thus is made sense to fold these back
into the main methods.
As part of doing this all of the tests for discipline were changed
to be in the same order.
Remove compare function and is unique indicator from the control
structure. Rename RBTree_Compare_function to RBTree_Compare. Rename
rtems_rbtree_compare_function to rtems_rbtree_compare. Provide C++
compatible initializers. Add compare function and is unique indicator
to _RBTree_Find(), _RBTree_Insert(), rtems_rbtree_find() and
rtems_rbtree_insert(). Remove _RBTree_Is_unique() and
rtems_rbtree_is_unique(). Remove compare function and is unique
indicator from _RBTree_Initialize_empty() and
rtems_rbtree_initialize_empty().
tm02 and tm03 were modified to be reused for multiple configurations
of RTEMS Classic API Semaphores. This added tm31-36. The messages for
tm02 and tm03 were modified to indicate the semaphore attributes.
tm31 - tm36 were added. This resulted in the following cases:
tm02 - rtems_semaphore_obtain: Counting/FIFO not available caller blocks
tm03 - rtems_semaphore_release: Counting/FIFO task readied preempts caller
tm31 - rtems_semaphore_obtain: Counting/priority not available caller blocks
tm32 - rtems_semaphore_release: Counting/priority task readied preempts caller
tm33 - rtems_semaphore_obtain: Binary/FIFO not available caller blocks
tm34 - rtems_semaphore_release: Binary/FIFO task readied preempts caller
tm35 - rtems_semaphore_obtain: Binary/priority not available caller blocks
tm36 - rtems_semaphore_release: Binary/priority task readied preempts caller
The priority affinity scheduler has the nice property that it can
produce more than one scheduled to ready state change in one operation.
Each scheduled to ready state change may lead to one thread in need for
help. Since it is currently only possible to return at most one thread
in need for help, we have a problem here.
A solution might be to move the check for migrations into the ask for
help mechanism.
Move the APBUART console driver support to the shared SPARC area so that
it can be reused by other BSPs. Only the console driver initialization
is now BSP specific.
Add a new low-level device API to Termios that passes the TTY structure
to the low-level device functions. This greatly simplifies the
low-level device drivers since they are no longer forced to derive their
private data from the minor number.
It makes it possible to use the TTY low-level lock in the device driver
low-level functions which is necessary for proper SMP support. For
example to set the attributes it is often necessary to perform a
read-modify-write operation on a control register used also by interrupt
routines.
A compatibility layer is provided to support device drivers using the
old callback functions so it is not necessary to modify existing device
drivers.
The following scheduler operations return a thread in need for help
- unblock,
- change priority, and
- yield.
A thread in need for help is a thread that encounters a scheduler state
change from scheduled to ready or a thread that cannot be scheduled in
an unblock operation. Such a thread can ask threads which depend on
resources owned by this thread for help.
Add a new ask for help scheduler operation. This operation is used by
_Scheduler_Ask_for_help() to help threads in need for help returned by
the operations mentioned above. This operation is also used by
_Scheduler_Thread_change_resource_root() in case the root of a resource
sub-tree changes. A use case is the ownership change of a resource.
In case it is not possible to schedule a thread in need for help, then
the corresponding scheduler node will be placed into the set of ready
scheduler nodes of the scheduler instance. Once a state change from
ready to scheduled happens for this scheduler node it may be used to
schedule the thread in need for help.
Return a thread in need for help for the following scheduler operations
- unblock,
- change priority, and
- yield.
A thread in need for help is a thread that encounters a scheduler state
change from scheduled to ready or a thread that cannot be scheduled in
an unblock operation. Such a thread can ask threads which depend on
resources owned by this thread for help.
This emphasizes that the scheduler node of a thread is returned and this
is not a function working with scheduler nodes like the other *_Node_*()
functions.
