Problems redirecting stdin/out for a task in 4.6.99.2

[Till Straumann]

Thomas Doerfler wrote:

> 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.

AFAIK, line-buffering tty devices is the required behavior (and is 
indeed what you observe --
if the stream was fully buffered [default behavior for non-tty files] 
nothing would be printed
at all (until fflush() or printing BUFSIZ chars).

> 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?

Hmm - I do something very similar in a modified version of telnetd.c and 
indeed did observe
something similar.

> - has anybody already fixed this?

Here's my workaround:

    /* newlib hack/workaround. Before we change stdin/out/err we must make
     * sure the internal data are initialized (fileno(stdout) has this 
sideeffect).
     * This should probably be done from RTEMS' libc support layer...
     * (T.S., newlibc-1.13; 2005/10)
     */
                                                                                                                                              

    fileno(stdout);
                                                                                                                                              

HTH
-- Till

>
> wkr,
> Thomas Doerfler.
>