blocking sends when the queue is full. The SuperCore was enhanced
to support blocking on send. The existing POSIX API was debugged
and numerous test cases were added to psxmsgq01 by Jennifer Averett.
SuperCore enhancements and resulting modifications to other APIs
were done by Joel.
There is one significant point of interpretation for the POSIX API.
What happens to threads already blocked on a message queue when the
mode of that same message queue is changed from blocking to non-blocking?
We decided to unblock all waiting tasks with an EAGAIN error just
as if a non-blocking version of the same operation had returned
unsatisfied. This case is not discussed in the POSIX standard and
other implementations may have chosen differently.
must deal with a pending process oriented signal. Prior to the addition
of this testcase, sigtimedwait() did not return properly when a process
oriented signal was pending. The problem was reported by Wayne
Bullaughey <wayneb@cacdsp.com>.
which ontains all what was left over from the other patches (Primarily
minor configuration cleanups).
To apply:
patch -p1 < rtems-rc-19991203-9.diff
./bootstrap
which does minor cleanup for Makefile.ams below mptests, which only
removes some bogus comments from the Makefile.ams.
To apply:
patch -p1 < rtems-rc-19991203-8.diff
./bootstrap
<corsepiu@faw.uni-ulm.de>:
The patch below provides
* automake support for score/cpu/powerpc
* The hack to propagate values from *.cfg to automake configuration
* A fix for librdbg/powerpc/mcp750/Makefile.am (Was completely corrupted
before)
* Fixes some files which apparently where missing in
rtems-rc-19991123-rc-2.diff
* some minor configuration related patches
To apply:
rm -rf ./c/src/exec/score/cpu/powerpc/wrap
patch -p1 < rtems-rc-19991123-rc-3.diff
Attention:
c/src/exec/score/cpu/[configure.in|aclocal.m4|configure] should be
removed after applying the patch.
Modifications had been made to the score/cpu/powerpc directory after
the snapshot this was based on. In particular, the mpc750 and
other_cpu directories had been renamed to new_exception_processing
and old_exception_processing. After this patch was applied, modifications
were made to account for this.
which (among other things) converted the mptests to automake.
SUB_DIRS was used instead of SUBDIRS in some Makefile.ins
(apparently a leftover from moving the start* directories)
Addtional major bugs:
* psxtests/include was empty (incomplete psxtests changes).
* bogus handling of *.scn in itrontests (screens/sptests vs.
screens/itrontests installation dirs)
In addition I have added a few more changes (I couldn't resist)
* automake support for itrontests
* OPERATION_COUNT support in tmitrontests/
* automake support for tmitrontests
* automake suppport for mptests
* Some (minor) corrections to several configure.in/Makefile.ams
=> c/src/tests/ is completly under automake control, now.
=> we could start to sort out the structural issues with c/src/tests
(tests/support, stubdr, tools, get "make dist" working)
+ Added tests for sem_open, sem_close, and sem_unlink.
+ Yellow lined sem_open, sem_close, sem_unlink,
_POSIX_Semaphore_Delete, _POSIX_Semaphore_Name_to_id,
and _POSIX_Semaphore_Create_support. Except for MP, pshared
OBJECT_REMOTE, and out of memory paths.
.. a major configuration cleanup
... major enhancement of automake support.
... and it contains a *major* breakthough:
Automake support for libchip and libmisc *LEAF* directories.
To implement this I have used several nasty tricks
* The basical trick is to wrap an old Makefile.in's contents into a
Makefile.am and still continue to use (i.e include) the old
*.cfg files.
* Replaced each INSTALL_IF_CHANGE and INSTALL_VARIANT with make
dependencies
* Add a gnu-make ifdef AUTOMAKE to main.cfg to avoid conflicts between
automake and RTEMS make rules
* Replaced each install:: and preinstall:: rule with make dependencies
* Replaced SUB_DIRS with SUBDIRS in all Makefile.ins (Automake
convention)
* Removed each manually added autoconf substitution which automake
performs automatically.
This is not yet full automake support, because using the temporary
installation directory, preinstallation in general and building variants
are in contradiction to automake's basic working principles ...
... the new Makefile.ams work still somewhat clumsy
... nevertheless they work (quite well).
WARNING:
At first glance this patch is small, but
* it affects the whole configuration system.
* it opens the road to introducing automake to all Makefile.ins
currently not being under automake control.
JOEL> Does this remove or add any files?
Both, all Makefile.ins below libchip and libmisc get replaced with
Makefile.ams.
Joel Sherrill
Jennifer Averett