in the unix port idle thread task. This should keep the entire application
from blocking when any component does a blocking application. Also added
TOD_MICROSECONDS_TO_TICKS.
was done based on the 3.6.0 release and had to be autoconf'ed locally.
It is turned on is the bsp enables it and it is not explicitly disabled
via the configure option --disable-tcpip. As many warnings as possible
were removed locally after the code was merged. Only the gen68360
and mvme136 bsps were compiled this way.
The ka9q port and network driver were submitted by Eric Norum
(eric@skatter.USask.Ca).
The network demo programs are not included in the tree at this point.
GNU autoconf. This is the first large step in allowing an RTEMS
user to perform a one-tree build (per crossgcc FAQ) including RTEMS
in the build process. With this change RTEMS is configured in
built in the same style as the GNU tools, yet retains the basic
structure of its traditional Makefiles (ala Tony Bennett).
Jiri Gaisler (jgais@wd.estec.esa.nl) deserves (and received)
a big thank you for doing this.
There are still issues to be resolved but as of this commit, all target
which can be built on a linux host have been using a modified version
of the source Jiri submitted. This source was merged and most targets
built in the tree before this commit.
There are some issues which remain to be resolved but they are primarily
related to host OS dependencies, script issues, the use of gawk
for hack_specs, and the dependence on gcc snapshots. These will
be resolved.
argument indicates whether the task is to be placed at the head or tail of
its priority fifo when it is lowering its own priority. POSIX normally
follows the RTEMS API conventions but GNAT expects that all lowering of
a task's priority by the task itself will result in being placed at the
head of the priority FIFO. Normally, this would only occur as the result
of lose of inherited priority.
argument indicates whether the task is to be placed at the head or tail of
its priority fifo when it is lowering its own priority. POSIX normally
follows the RTEMS API conventions but GNAT expects that all lowering of
a task's priority by the task itself will result in being placed at the
head of the priority FIFO. Normally, this would only occur as the result
of lose of inherited priority.
The RTEMS API always puts tasks at the end of their priority group except
upon loss of inherited priority.
