fileno(stdin) versus STDIN_FILENO and friends

[Chris Johns]

On 15/03/11 10:10 AM, Peter Dufault wrote:
>
> On Mar 14, 2011, at 6:56 , Chris Johns wrote:
>
>> I think it is reasonable to make this change. The whole shell and telnet
>> on RTEMS is an application trick to make the RTEMS "process" appear
>> multi-user and process based. We should attempt to make this emulation
>> appear as standard.
>
> I think (but don't know, but would like to know) that we're talking about behavior that isn't defined by a standard. If the behavior is defined, then RTEMS should ensure things follow the standard, but I haven't located a definition yet.

I do not know of a standard for managing these things inside a process 
environment. The standards talk about processes and this is what we are 
attempting to emulate with the shell and telnet. This is what I was 
referring to.

> If we're operating outside of any definition

I think we are because you are using part of some application type code 
that is the shell and telnet and here we would like the process 
standards to apply if they make sense and it can be done.

> then I suggest RTEMS make the stdio thread inheritance behavior optional: I'd prefer an inherited stdin,stdout,stderr, and I'll look at what it takes to make it work in the newlib framework.  Others might like the way it works now, where all threads revert to file descriptors 0, 1, and 2 for stdin, stdout, and stderr for newly created threads.

I agree for the shell and telnet type code and here I would make the 
behaviour you want as the default.

For me the general thread create case will have wait and be based on 
what you discover.

Chris