substantial upgrade of newlibc.c occurred. Now the user extension
data area is used rather than notepads and as many routines as possible
were split into other files further reducing the minimum footprint
of an RTEMS executable.
unnecessarily uses any variables defined by the BSP. On this
sweep, use of BSP_Configuration and Cpu_table was eliminated.
A significant part of this modification was the addition of
macros to access fields in the RTEMS configuration structures.
This is necessary to strengthen the division between the BSP independent
parts of RTEMS and the BSPs themselves. This started after
comments and analysis by Ralf Corsepius <corsepiu@faw.uni-ulm.de>.
I'm working on code to mount my host based file system on the base file
system (imfs) and have a suggestion for a change to eval.c in the
c/src/lib/libc directory of the 8/20/1999 snapshot. The current version
does not test the result value returned from the evalpath callback (line 47)
in the case where follow_link is true. Attached is my suggested change.
Without this test the node_type callback may be called after evalpath
failed. node_type could set the type to some value other then
RTEMS_FILESYSTEM_HARD_LINK or RTEMS_FILESYSTEM_SYM_LINK but it seems cleaner
to add the check on result.
Here is another fix, which addresses a few more or less severe bugs in
configuration and unix/posix:
* Configuration fix: c/src/lib/configure.in didn't handle RDBG correctly
* Configuration fix: make depend was non-functional in
c/src/lib/libc/Makefile.in
* Configuration fix: stray comment removed from aclocal/target.m4
* RTEMS fix: termios support for unix/posix now uses the host's headers
only (was completely broken).
- Don't install RTEMS's newlib sys/termios.h for unix (sys/termios.h
apparently is a newlib specific header)
- To be able to compile RTEMS's termios.c with glibc2.1, glibc-2.1
needs __USE_MISC, which is a private define from gcc's features.h, being
defined only when _BSD_SOURCE of _SVID_SOURCE is defined. RTEMS's
termios apparently implements BSD, thus -D_BSD_SOURCE was added to
Linux-posix.cfg.
- Conflicting definitions for __USE_MISC and _BSD_SOURCE inside of
RTEMS codes removed due to definition of _BSD_SOURCE on the toplevel.
This fix has been tested with linux/posix (primary glibc2.1 native),
linux/posix (secondary libc5 native), sh/gensh1, i386/pc386 and a couple
of other bsp's/CPU.
To apply:
cd <srcdir>
patch -p1 < rtems-rc-19990709-9.diff
and
aclocal -I aclocal && automake && autoconf
cd c/src/lib; autoconf
or
./autogen
that the per task reentrancy structure was not being processed properly
during exit().
joel@oarcorp.com wrote:
>
>
> This is always an ugly place to poke around. :(
>
> The code in newlib/libc/stdlib/exit.c walks the atexit chain for the
> reentrancy structure for JUST the current task. The code in libc_wrapup()
> does it for both the current task and the global reentrancy structure
> (which tends to be where driver atexit()'s were registered.
>
> So I think the _wrapup_reent(0) in libc_wrapup() should be commented out.
>
> If you concur, then I will make the change and improve the comment on this
> line of code to explain things:
>
> libc_wrapup(); /* Why? XXX */
>
> --joel
That does the job. cdtest.exe works correctly now.
<e.norum@sk.sympatico.ca> and concerns from Thomas Doerfler
<td@imd.m.ISAR.de> when he submitted the patch:
Since enabling XON/XOFF has such a major performance hit on `smart' output
devices I think it should be *off* by default. I think some thought should
be given to adding hooks for hardware that can support XON/XOFF without
software intervention, or for hardware like the 68360 SCC's that can use
large buffers, but still handle special characters immediately.
The patch you sent is a very good start, though. I just think that the
software flow control should be off -- to match the way the serial I/O
support has worked up until now.
Some lines for "documentation":
======================================
One thing should be noted: when XON/XOFF is enabled, the serial
device will always work with one-character buffers, so the interrupt
load for the CPU might get higer, especially on devices like MC68360
and MPC860, where the serial channels are capable of using big
buffers. But, once again, this only happens when XON/XOFF is actually
selected.
Please note that the flag IXON is set by default, so outgoing
XON/XOFF flow control is enabled by default.
XON/XOFF is controlled using the "standard" fields IXON/IXOFF in the
termios structure. The termios flag IXANY is not (yet) supported.
Hardware handshake for the incoming data stream is controlled using
the standard flag CRTSCTS. If this flag is set, whenever the receive
buffer is almost full, the driver function "device.stopRemoteTx()" is
called, when the receive buffer has more space available,
"device.startRemoteTx()" is called again. If the driver does not
provide these interface functions (entries in device structure are
NULL pointers), then these calls are suppressed.
Changes of the flow control options during operation should work at
any time, but this has not been extensively tested.
No changes to the device driver interface are needed.
================================================
One critical point when using this patch might be, that any BSP using
this version of termios will now have outgoing flow control enabled
by default, so the behaviour of these BSPs will change here. The
option IXON has already been set in older termios by default, but it
did not work until this patch. Maybe this option should be switched
off by default, what do you think?
would work. At the same time, the initial implementation of F_SETFL
was added. A support routine was added to convert internal libio
flags back to the POSIX style. Eventually the internal representation
should be eliminated in the interest of simplicity and code reduction.
This problem was reported by Jake Janovetz <janovetz@tempest.ece.uiuc.edu>.
rather then NAME_MAX. NAME_MAX is 255 and that lets IMFS chew up memory
too fast. Perhaps in the future, the places in IMFS that put a maximum
length name string on the stack and the jnode structure does not include
a maximu length name string can be fixed so this is not a problem.
Joel Sherrill
Jennifer Averett