This patch is a newer version of the test presented on
http://www.rtems.org/pipermail/rtems-devel/2014-February/005318.html
Unchecked error cases:
- EIO (physical error)
- ENOSPC (no space left in the new filepath)
- EROFS (already covered on testsuites/fstests/fsrofs01)
Untested functionality:
- File system lock during rename() operation
- If after rename() the link count of a file becomes 0 it should be
removed and the space ocupied by the file shall be freed and no longer
accessible (the function statvfs() gives "not implemented" on the imfs
file system, so this is postponed for now)
We have a unified work area. So depending on the memory layout the
task_id_p = malloc( sizeof( rtems_id ) );
rtems_test_assert( task_id_p );
or the
sc = rtems_task_create(
rtems_build_name('T','A',created_task_count, ' '),
1,
RTEMS_MINIMUM_STACK_SIZE,
RTEMS_DEFAULT_MODES,
RTEMS_DEFAULT_ATTRIBUTES,
task_id_p
);
rtems_test_assert(
(sc == RTEMS_UNSATISFIED) ||
(sc == RTEMS_TOO_MANY) ||
(sc == RTEMS_SUCCESSFUL)
);
may fail. If we are unlucky then we hit the first case and the test
fails.
Add a local context structure to the SMP lock API for acquire and
release pairs. This context can be used to store the ISR level and
profiling information. It may be later used to enable more
sophisticated lock algorithms, e.g. MCS locks.
There is only one lock that cannot be used with a local context. This
is the per-CPU lock since here we would have to transfer the local
context through a context switch which is very complicated.
This partially reverts commit 1215fd4d94.
In order to support profiling of SMP locks and provide a future
compatible SMP locks API it is necessary to add an SMP lock destroy
function. Since the commit above adds an SMP lock to each chain control
we would have to add a rtems_chain_destroy() function as well. This
complicates the chain usage dramatically. Thus revert the patch above.
A global SMP lock for all chains is used to implement the protected
chain operations.
Advantages:
* The SAPI chain API is now identical on SMP and non-SMP
configurations.
* The size of the chain control is reduced and is then equal to the
Score chains.
* The protected chain operations work correctly on SMP.
Disadvantage:
* Applications using many different chains and the protected operations
may notice lock contention.
The chain control size drop is a huge benefit (SAPI chain controls are
66% larger than the Score chain controls). The only disadvantage is not
really a problem since these applications can use specific interrupt
locks and unprotected chain operations to avoid this issue.
Formerly POSIX keys were only enabled when POSIX threads
were enabled. Because they are a truly safe alternative
to per-task variables in an SMP system, they are being
enabled in all configurations.
This method exercises the ability to dynamically get and set
the affinity of POSIX threads.
NOTE: There is no scheduler support for affinity. This is
simply a data integrity test.
Rename _SMP_Request_other_cores_to_perform_first_context_switch() into
_SMP_Request_start_multitasking() since this requests now a multitasking
start on all configured and available processors. The name corresponds
_Thread_Start_multitasking() and
_SMP_Start_multitasking_on_secondary_processor() actions issued in
response to this request. Move in source file to right place.
Rename PER_CPU_STATE_READY_TO_BEGIN_MULTITASKING into
PER_CPU_STATE_READY_TO_START_MULTITASKING.
Rename PER_CPU_STATE_BEGIN_MULTITASKING into
PER_CPU_STATE_REQUEST_START_MULTITASKING.
Rename _SMP_Request_other_cores_to_shutdown() into
_SMP_Request_shutdown().
Add a per-CPU state lock to protect all changes. This was necessary to
offer a controlled shutdown of the system (atomic read/writes alone are
not sufficient for this kind of synchronization).
Add documentation for Per_CPU_State.
Delete debug output.
New tests smptests/smpfatal01 and smptests/smpfatal02.
Remove RTEMS_COMPILER_PURE_ATTRIBUTE from _SMP_Get_current_processor()
and all _CPU_SMP_Get_current_processor(). Make inline ASM statements
volatile again. Test smptests/smpmigration01 showed that GCC optimizes
too much otherwise.
Use rtems_fatal() instead of _CPU_Fatal_halt() to shutdown processors in
SMP configurations since this allows intervention of BSP or application
specific fatal extensions.
Merge RTEMS_FATAL_SOURCE_BSP_GENERIC and RTEMS_FATAL_SOURCE_BSP_SPECIFIC
into new fatal source RTEMS_FATAL_SOURCE_BSP. This makes it easier to
figure out the code position given a fatal source and code.
