| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
| |
Ralf Corsepius <corsepiu@faw.uni-ulm.de>.
|
|
|
|
|
|
|
| |
Janovetz <janovetz@tempest.ece.uiuc.edu> to return a status from
network initialization rather than panic'ing. It changes a bunch
of rtems_panics to printfs and returns a status from
rtems_bsdnet_initialize_network().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'd like to propose a change to RTEMS task variables that I think would
make them more useful. I think that it is early enough in their
existence to still make changes to their API.
1) Change type from `int' to `void *'.
2) Add extra argument to task_variable_add -- if non-NULL, a pointer to
a `destructor' function to be called when the task exits. This function
would be called with that task's value of the task variable as its
argument. In many cases, the `dtor' function could be `free'.
rtems_status_code rtems_task_variable_add (
rtems_id tid, void **ptr, void (*dtor)(void *));
rtems_status_code rtems_task_variable_delete (rtems_id tid, void **ptr);
This would be all we'd need to cleanly and efficiently support C++
per-thread exception information without dragging in all that POSIX API
stuff.
|
| |
|
|
|
|
|
|
|
|
| |
Some excellent sleuthing by Bob Wisdom <bobwis@ascweb.co.uk> revealed
that an empty mbuf at the end of a packet chain would cause the `retire'
function to blow up. Moving the line of code which bumps the transmit
buffer descriptor pointer fixes the problem. Some additional cleanup of
the sendpacket function was also completed.
|
| |
|
| |
|
|
|
|
| |
is not strict ANSI.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that addresses the librdbg/rpcgen related problems:
Changes:
* All rpcgen generated files are now kept inside of the source tree
* Fix librdbg/configure to correctly detect presence of rpcgen and awk
* Use rpcgen -m to generated remdeb_svc.c
* Remove msgout/_msgout from awk.svc
* minor cleanups to librdbg/configure.in
ATTENTION --- IMPORTANT:
* With keeping rpc-generated files pre-build inside of the source tree,
you as the packager of RTEMS have to ensure that timestamps are
correctly set up: The generated files must not be older than the *.x
files.
* This is extraordinarily important when
- putting the package on read-only media
- after checking out from CVS
- after modifications to the *.x files
* If one of the *.x files is modified you have to either
- build for i386/pc386 and powerpc/mcp750
- or to invoke the same rpcgen calls as the
librdbg/src/<cpu>/<bsp>/Makefile.am do manually
before checking-in the files to CVS.
Proposal:
We could add something to bootstrap for touching the rpcgen-generated
sources and/or to manually regenerate them.
NOTE FROM JOEL:
Ralf proposed modifying bootstrap to handle rpcgen. I think this
is the best solution as it is something already done in the
snapshot procedure.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
because of the conversion to automake and replaced by a Makefile.am.
|
| |
|
|
|
|
|
| |
and _CORE_message_queue_Insert_message for posix message queues.
+ Yellow line tested new source
|
| |
|
| |
|
|
|
|
| |
Added correct include file.
|
| |
|
| |
|
|
|
|
| |
and memory layout. Next step is to share the same bsp_pretasking_hook.
|
| |
|
| |
|
| |
|
|
|
|
| |
+ Yellow lined tested routine with Posix message queue test (01)
|
| |
|
|
|
|
|
| |
+ Added messsage size check
+ Debugged and yellowed out routine
|
|
|
|
| |
+ Yellow line tested source.
|
|
|
|
|
| |
+ Removed extra flag attribute from message queue structure.
+ Yellow-lined all posix message queue routines.
|
|
|
|
| |
queues as well as the messages.
|
| |
|
|
|
|
| |
that converts the libbsp/i386 subdirectory to full automake.
|
|
|
|
|
|
|
|
| |
for the gen68360 that let it work with ELF and C++ exceptions. This
was used as the basis for changes to EVERY m68k bsp_specs and linkcmds.
Before this modification is over, the layout of the starting stack,
heap, and workspace will likely be modified for every m68k BSP. Then
they will all be very similar.
|
|
|
|
| |
that converts the libbsp/i386 subdirectory to full automake.
|
|
|
|
|
|
|
|
|
|
| |
that fixes the following problems:
1. Removing bogus ';' in some configure.in (cosmetical fix)
2. Moves GAS_CODE16 checks to libbsp/i386/*/configure.in (essential fix)
#2 was responsible for the gcc/binutils-2.9.5 choking while building for
the pc386.
|
| |
|
|
|
|
|
|
|
| |
being set to 0 to indicate that there should be no Clock Tick. This
was used by the Timing Tests to avoid clock tick overhead perturbing
execution times. Now the Timing Tests simply leave the Clock Tick
Driver out of the Device Driver Table.
|
|
|
|
|
| |
expansion. These macros were modified to correct warnings and
obviously needed more parentheses to expand correctly.
|