Problems redirecting stdin/out for a task in 4.6.99.2
Thomas Doerfler
Thomas.Doerfler at imd-systems.de
Mon Nov 28 07:04:15 UTC 2005
Hi,
I have just ported a piece of test code from rtems-4.6.0pre4 to 4.6.99.2
on a PowerPC 603 machine. I am workling with the gcc-4.0.1 toolset. I
have detected two issues concerning stdio functionality:
1. It seems the newlib no longer detects, that a given path is a tty
(serial console) device, it performs line buffering on the output
stream. The effect is as follows:
printf("Hello, this is Task xxx\n");
printf("Enter your input==>");
The above code only outputs the first line, the second one only comes up
when a further printf also adds a "\n" to the output stream. Adding a
"fflush(stdout)" after the second printf makes the prompt visible, but I
am quite sure this was not neccesary for character devices in earlier
RTEMS versions.
2. (And this is worse): I instantiate the same sample code in multiple
tasks, each task uses a different serial device for I/O. See the
following code:
---snip----------------------------
rtems_task v24_demo_task(rtems_task_argument arg)
{
const char *stddev = (const char *)arg;
rtems_status_code sc = RTEMS_SUCCESSFUL;
int tsk_fd;
/*
* open new device
*/
tsk_fd = open(stddev,O_RDWR);
write(tsk_fd,stddev,9);
if (tsk_fd < 0) {
sc = RTEMS_IO_ERROR;
fprintf(stderr,"Can't open %s for V.24 demo task: %s",
stddev,
strerror(errno));
}
/*
* assign paths to stdin/out
*/
if (sc == RTEMS_SUCCESSFUL) {
stdin = fdopen(tsk_fd,"r");
if (stdin == NULL) {
sc = RTEMS_IO_ERROR;
}
}
if (sc == RTEMS_SUCCESSFUL) {
stdout = fdopen(tsk_fd,"a");
if (stdout == NULL) {
sc = RTEMS_IO_ERROR;
}
}
if (sc != RTEMS_SUCCESSFUL) {
fprintf(stderr,"Can't fdopen %s for V.24 demo task: %s",
stddev,
strerror(errno));
}
while (sc == RTEMS_SUCCESSFUL) {
/*
* print info (own path etc)
*/
printf(" Hi, you are talking to the demo task on %s\n",stddev);
printf("Enter expression or==>");
---snip--------------------------
The intention is that this code redirects stdin/stdout to the device
passed in the "arg" argument ("/dev/tty1", "/dev/tty2"...) when the task
is started. Strange things happen:
The first "write" call really sends output to the desired interface.
When I inspect the "_impure_ptr" for this task, I can also see that the
_stdin/_stdout structure contains the proper "_file" parameter, before
the first printf is called. But after the printf call returns,
_impure_ptr->_stdout->_file has been rewritten with "1", which seems the
"default" value for stdout. Before I start digging into newlib, I would
like to know:
- has the mechanism to redirect stdio changed?
- has anybody else detected the same effects?
- has anybody already fixed this?
wkr,
Thomas Doerfler.
--
--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler Herbststrasse 8
D-82178 Puchheim Germany
email: Thomas.Doerfler at imd-systems.de
PGP public key available at:
http://www.imd-systems.de/pgpkey_en.html
More information about the users
mailing list