RTEMS untar implementation had problems with overwriting or integrating
archives into existing directory structures. This patch adapts the
behavior to mimic that of a GNU tar or BSD tar and extends the tar01
test to check for the behavior. That is:
* If a directory structure exists, the files from the archive will be
integrated. Existing files are overwritten.
* If a file exists and the archive contains a directory with the same
name, the file is removed and a directory is created. In the above
example: if l1/l2 is a file it will be overwritten with a new
directory.
* If a directory exists and the archive contains a file with the same
name, the directory will be replaced if it is empty. If it contains
files, the result is an error.
* An archive also can contain only a file without the parent
directories. If in that case one of the parent directories exists as a
file extracting the archive results in an error. In the example: if
l1/l2 is a file and the archive doesn't contain the directories but
only the file l1/l2/x.txt that would be an error.
* In case of an error, it is possible that the archive has been
partially extracted.
Closes#4568
In _Workspace_Initialize_for_one_area(), properly check if there is enough
free memory available for the configured workspace size.
The bug was introduced by commit 3d0620b607.
Since the previous Interrupt Manager Extension API moved to the
Interrupt Manager, we can move the interfaces to <rtems/rtems/intr.h> so
that they are available via #include <rtems.h>.
The BSPs provide memory for the separate C Program Heap initialization
via _Memory_Get(). Most BSPs provide exactly one memory area. Only two
BSPs provide more than one memory area (arm/altera-cyclone-v and
bsps/powerpc/mpc55xxevb). Only if more than one memory area is
provided, there is a need to use _Heap_Extend(). Provide two
implementations to initialize the separate C Program Heap and let the
BSP select one of the implementations based on the number of provided
memory areas. This gets rid of a dependency on _Heap_Extend(). It
also avoids dead code sections for most BSPs.
Change licence to BSD-2-Clause according to file history.
Update #3053.
The BSPs provide memory for the workspace initialization via
_Memory_Get(). Most BSPs provide exactly one memory area. Only two
BSPs provide more than one memory area (arm/altera-cyclone-v and
bsps/powerpc/mpc55xxevb). Only if more than one memory area is
provided, there is a need to use _Heap_Extend(). Provide two
implementations to initialize the workspace handler and let the BSP
select one of the implementations based on the number of provided memory
areas. This gets rid of a dependency on _Heap_Extend(). It also avoids
dead code sections for most BSPs.
Affected components are the GR712RC, UT699, UT699E, UT700, and
LEON3FT-RTAX. Strictly, the workaround is only necessary if the MMU is
enabled. Use __FIX_LEON3FT_B2BST to enable the workaround. This is not
100% appropriate, but the best thing we can use to enable the
workaround.
Close#4551.
The _Thread_queue_Extract() does not deal with potential priority
updates and the SMP locking protocol handling. Use
_Thread_queue_Continue(). For the POSIX signals processing this is
currently probably unnecessary, however, the use case is similar to the
restart so use the same appoach.
Close#4546.
Remove the THREAD_WAIT_STATE_READY_AGAIN and simply use the initial value to
indicate that a thread does not wait on something. Rename
THREAD_WAIT_FLAGS_INITIAL to THREAD_WAIT_STATE_READY. This change is necessary
so that _Thread_Continue() can be called for threads which never waited on
something (for example dormant threads).
Update #4546.
Remove _Thread_queue_Extract_with_proxy() and move the proxy extraction
to _Thread_MP_Extract_proxy(). Move similar code blocks of the previous
caller of _Thread_queue_Extract_with_proxy() to helper functions.
Update #4546.
The SMP EDF scheduler supports a one-to-one and one-to-all thread to
processor affinity. It accepted affinity sets which are a proper
subset of the online processor containing at least two processors owned by
the scheduler. In this case it used a one-to-one thread to processor
affinity. This leads to undefined behaviour if a processor is removed
since the higher level check in rtems_scheduler_remove_processor() does
not account for this implementation detail.
Restrict the affinity set accepted by the SMP EDF scheduler to
1. all online processors, or
2. exactly one processor owned by the scheduler.
Close#4545.
Return an error status for the following error condition in
rtems_scheduler_remove_processor():
While an attempt is made to remove a processor from a scheduler, while
the processor is the only processor owned by the scheduler, if a thread
exists which uses the scheduler as a helping scheduler, then the
processor shall not be removed.
The reason is that ask for help requests and withdraw node requests are
processed asynchronously in any order. An ask for help request carried
out on a scheduler without a processor is undefined behaviour.
Update error status description.
Update #4544.
Process ask for help requests on the current processor. This avoids
using inter-processor interrupts to make the system behaviour a bit more
predictable.
Update #4531.
Simplify callers of _Scheduler_SMP_Schedule_highest_ready(). Move the node
state change and the extraction from scheduled into
_Scheduler_SMP_Schedule_highest_ready(). Move the idle thread release to the
caller which have more information about the presence of an idle thread.
Update #4531.
The SMP EDF scheduler supports one-to-one and one-to-all thread to
processor affinities. The one-to-one thread to processor affinity
introduces a constraint on the ordering of threads. The implementation
uses one ready queue for threads which have a one-to-all affinity and
one for each one-to-one affinity group. To order threads across the
ready queues, a generation number is used. However, the approach to
update the generation number each time a thread is inserted into a ready
queue was wrong. The generation number needs to be updated only in the
enqueue and enqueue scheduled operations where an insert priority is
available. The scheduled chain needs to take the generation number into
account.
An example scenario which shows the bug is this. Let T be a high
priority task affine to processor X. Let A be a lower priority task
affine to processor X. Let B be a lower priority task with no affinity
to a particular processor which executes on processor Y. Let B be in
the same priority group than A and after A. Let T set the affinity to
all processors. Now A (higher priority relative to B) should execute on
X and T (high priority) should execute on Y.
Close#4534.
This patch fixes an issue with the idle thread handling in the SMP
scheduler framework used for the MrsP locking protocol. The approach to
use a simple chain of unused idle threads is broken for schedulers which
support thread to processor affinity. The reason is that the thread to
processor affinity introduces another ordering indicator which may under
certain conditions lead to a reordering of idle threads in the scheduled
chain. This reordering is not propagated to the chain of unused idle
threads. This could lead to use an idle thread for a sticky scheduler
node which is already in use. This locks up the system in infinite
loops in the thread context switch procedure.
To fix this, the SMP scheduler implementations must now provide
callbacks to get and release an unused idle thread.
Update #4531.
This patch fixes the following broken behaviour:
While a thread is scheduled on a helping scheduler, while it does not
own a MrsP semaphore, if it obtains a MrsP semaphore, then no
scheduler node using an idle thread and the ceiling priority of the
semaphore is unblocked for the home scheduler.
This could lead to priority inversion issues and is not in line
with the MrsP protocol.
Introduce two new scheduler operations which are only enabled if
RTEMS_SMP is defined. The operations are used to make the scheduler
node of the home scheduler sticky and to clean the sticky property.
This helps to keep the sticky handing out of the frequently used
priority update operation.
Close#4532.
If a node is moved from the scheduled chain to the ready queue, then we
know that it is the highest priority ready node. So, it can be
prepended to the ready queue without doing any comparisons.
Update #4531.
Rework the handling of the affine ready queue for the EDF SMP scheduler.
Do the queue handling in the node insert, move, and extract operations.
Remove the queue handling from _Scheduler_EDF_SMP_Allocate_processor().
Update #4531.
Insert nodes after moving the second node to reduce the items in the
data structure for the insert operation. This also avoids having two
nodes for the same processor inserted into the scheduled chain.
Update #4531.
Do not set the CPU of the idle thread in _Scheduler_Use_idle_thread(). This
helps to use _Scheduler_Try_to_schedule_node() under more general conditions in
the future, for example in case the owner and user of a node are not the same.
Update #4531.
