Test the proper serialization of explicit thread priority changes (for
example rtems_task_set_priority()) and thread priority changes carried
out by thread queues (locking protocols such as priority inheritance).
With RTEMS_DEBUG enabled, the new test case fails with an assertion. It
is fixed in a follow up commit.
Update #5159.
Change the time to convert so that rounding issues do not propergate to
the second next digit. Properly round the result used for the precision
estimate.
The RTEMS_UNREACHABLE() is a hint to the compiler that this code
location is unreachable. The compiler may use this information to
optimize the code. If a test case fails and we reach this code
location, then unpredictable things may happen making the test case
debugging more difficult than necessary.
This reverts commit c1aa06dbd2.
Extending the rtems_stack_checker_info like this breaks the existing
visitor API used by rtems_stack_checker_iterate(). After review, using
an information structure contradicts the intention of the reporter to
allow a minimal reporting. Filling up the information structure with
all the details would pull in several dependencies, like
_Thread_Get_name(). The API should be improved to provide the user with
the necessary information from the TCB without having to access members
directly.
Modified the body of lio_listio(), to make sure it return -1 and sets
errno to ENOSYS, when RTEMS_POSIX_API is not defined.
The psxenosys test has been modified to test for lio_listio() only
when RTEMS_POSIX_API is not defined. In the test all the puts() have
been removed. If kept they would have made the output of the test depending
on the build configuration, making the content of psxenosys.scn inconsistent.
Removing the puts() makes the .scn file valid regardless of the build
configuration.
Additionally, rtems_aio_notify() in aio_misc.c has been modified,
simplifying it and reducing the part inside the ifdef.
Closes#5125
This commit adds support for lio_listio().
psxaio05 has been added to test the new method.
To avoid code duplication, the body of aio_read and aio_write has been
moved in two helper methods. In this way i can use it also in lio_listio().
In addition to that, a limit on the number of total aio operation enqueued
has been added.
Updates rtems/programs/gsoc#29
This follows current conventions.
Two have been left behind for now until we decide what to do as they are
imports.
* cpukit/compression/xz/COPYING
* cpukit/libmisc/uuid/COPYING
In _Terminate(), everything after invoking the fatal extensions is essentially
dead code. Simplify this code block and provide a reasonable safe fall-back
for badly configured applications. Just disable masked interrupts and execute
an idle loop.
Update #5067.
Now as the default reporter is set to be a quiet reporter, we have stackchk test case for the default quiet reporter, stackchk03 for a custom user-defined reporter and stackchk04 for the detailed reporter function
The testcase failed because the rmdir call in that case had two possibilities to fail and the implementation of rmdir checked the other possibility first.
Closes#5071
Changed fstest support to allow control on the test result of each fstest, updated all fstest accordingly.
Modified FS_FAIL macro to fail hard and not just print a message which rtems-test runner ignores.
Split failing test cases from the ones that passes; added fsrenameexisting, fsrenamepermexisting, fsrmdirparent, fsrenamelongname and fsrenamemaxlinks test cases.
Marked fsrenameexisting, fsrenamepermexisting as expected to fail due to #2169.
Marked fsrmdirparent as expected to fail, covered by #5071.
Marked fssymlink as expected to fail due to rename problems partially covered by #2169.
Marked rfsfsrenamelongname as expected to fail, covered by #5069.
Marked *fsrenamemaxlinks as expected to fail, covered by #5070.
Marked jffs2fsrenamelongname and jffs2nandfsrenamelongname as expected to fail, as JFFS2 seems to not have a limit on the file name, covered by #5073
rename now actively changes the inode of the file being renamed.
This change has been done to fix an issue when the file being renamed is already opened before the rename, in particular failing to update the inode number (and the two lookup tables) could cause at least two problems:
1) A new file created in the same source folder of the file being renamed may get the same fat file descriptor of the renamed file
2) An open to the renamed file opens a new fat file descriptor, thus putting out of sync the operations on the file (two distinct fat file descriptor working on the same clusters and entries)
Previously the inode was in any case changed once the file was closed.
Another possible solution would have been to separate the inode number from the lookup table, but this solution would have required much more memory because it needed to keep track of all files seen in the file system up to the last operation and not only the opened ones.
Closes#5044
The patch adds the generation of a notification after an Asynchronous I/O
request has been completed. The notification is generated using the aio_sigevent
filed in the aiocb struct, as defined by the posix specifiations.
A new control, ensuring the validity of the field, is added on each call to
aio_read(), aio_write() and aio_fsync().
The patch also adds tests to cover the new code, and fixes formatting errors of
various aio files.
