[ECOS] sdtin/stdout/stderr redirection

[ECOS] sdtin/stdout/stderr redirection

[Philippe Vandermersch]

Hi,

I have created a filesystem over PCI which actually allows the Hosted 
PCI board running eCos to access the Filesystem of the Host (running Linux).
Now I would like to know if it is possible to redirect dynamically eCos 
sdtin/stdout/stderr to some other fd than the usual 0,1,2.
My idea is to open  the Linux stdin,sdtout,stderr and to affect the fd 
obtained through my filesystem to the eCos ones.

Philippe



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] sdtin/stdout/stderr redirection

[Jonathan Larmour]

Philippe Vandermersch wrote:
> Hi,
> 
> I have created a filesystem over PCI which actually allows the Hosted 
> PCI board running eCos to access the Filesystem of the Host (running 
> Linux).
> Now I would like to know if it is possible to redirect dynamically eCos 
> sdtin/stdout/stderr to some other fd than the usual 0,1,2.
> My idea is to open  the Linux stdin,sdtout,stderr and to affect the fd 
> obtained through my filesystem to the eCos ones.

Strictly the way to do this is using freopen() but that isn't fully 
supported by eCos, although it wouldn't be difficult at all - just dropped 
off the end several years ago now!

You could even just do it yourself using fclose() and fdopen() and 
assigning to stdin - there's nothing else required AFAIK.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] sdtin/stdout/stderr redirection

[Philippe Vandermersch]

Jifl.

I liked your proposal because I do not have to deal with C++ but :

1)
fclose( stdout ) failed :
ASSERT FAIL: <4>dlmalloc.cxx[765]do_check_chunk() (cyg_uint8 *)p >= 
arenabase
ASSERT FAIL: <4>dlmalloc.cxx [ 765] do_check_chunk() (cyg_uint8 *)p >= 
arenabase
TRACE: <4>sched.cxx [ 705] disinherit_priority() }}RETURNING UNSET!
TRACE: <4>mutex.cxx [ 447] unlock()

2)
If I do not close it and do simply : stdout = fdopen(fd_out , "w" ) 
seems to succeed but printf does print anything

3)
To make it work, I had to do this in C++:

Cyg_StdioStream *StdoutStream = new Cyg_StdioStream( fd_out, 
Cyg_StdioStream::CYG_STREAM_WRITE, false, false, _IOLBF );
if(StdoutStream == NULL) return( ENOMEM );
stdout = (FILE *)StdoutStream;

It also works for stdin,stderr.

Phil.

Jonathan Larmour wrote:

> Philippe Vandermersch wrote:
>
>> Hi,
>>
>> I have created a filesystem over PCI which actually allows the Hosted 
>> PCI board running eCos to access the Filesystem of the Host (running 
>> Linux).
>> Now I would like to know if it is possible to redirect dynamically 
>> eCos sdtin/stdout/stderr to some other fd than the usual 0,1,2.
>> My idea is to open the Linux stdin,sdtout,stderr and to affect the fd 
>> obtained through my filesystem to the eCos ones.
>
>
> Strictly the way to do this is using freopen() but that isn't fully 
> supported by eCos, although it wouldn't be difficult at all - just 
> dropped off the end several years ago now!
>
> You could even just do it yourself using fclose() and fdopen() and 
> assigning to stdin - there's nothing else required AFAIK.
>
> Jifl





-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] sdtin/stdout/stderr redirection

[Jonathan Larmour]

Philippe Vandermersch wrote:
> Jifl.
> 
> I liked your proposal because I do not have to deal with C++ but :
> 
> 1)
> fclose( stdout ) failed :
> ASSERT FAIL: <4>dlmalloc.cxx[765]do_check_chunk() (cyg_uint8 *)p >= 
> arenabase
> ASSERT FAIL: <4>dlmalloc.cxx [ 765] do_check_chunk() (cyg_uint8 *)p >= 
> arenabase
> TRACE: <4>sched.cxx [ 705] disinherit_priority() }}RETURNING UNSET!
> TRACE: <4>mutex.cxx [ 447] unlock()

Bugger, I forgot about that. fclose() is trying to free stdin, but stdin 
was not allocated off the heap.

> 2)
> If I do not close it and do simply : stdout = fdopen(fd_out , "w" ) 
> seems to succeed but printf does print anything

Ah... my guess is that the default buffering mode is full buffering, not 
line buffering, so you would have to set the buffering mode to _IOLBF with 
setvbuf().

If it's not that I'm afraid I don't know off-hand what it could be. 
fdopen() calles fopen_inner() in fopen.cxx, which calls a constructor just 
like you do below.

> 3)
> To make it work, I had to do this in C++:
> 
> Cyg_StdioStream *StdoutStream = new Cyg_StdioStream( fd_out, 
> Cyg_StdioStream::CYG_STREAM_WRITE, false, false, _IOLBF );
> if(StdoutStream == NULL) return( ENOMEM );
> stdout = (FILE *)StdoutStream;
> 
> It also works for stdin,stderr.

That's good. Although if you had a moment, it would be nice if you could 
have a quick poke around to see why 2) didn't work, and in particular if 
using setvbuf(stdout, NULL, _IOLBF, BUFSIZ); is all it takes.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] sdtin/stdout/stderr redirection

[Philippe Vandermersch]

Jifl,

You are right. It is opened in full buffering mode. A call to 
setvbuf(stdout, NULL, _IOLBF, BUFSIZ) works
Thanks.

Another question:
Why the open mode #define like O_CREAT, O_RD_ONLY..... are not the same 
definition than in Linux
Same question for the st_mode in struct stat  (VxWorks and Linux has the 
same definition)
It would make my life easier.....

I notice that eCos manage the binary mode for fopen but somehow it is 
lost along the road when calling open (which triggers my filesystem 
rpcfs_open routine)
Is there any intention to define O_BINARY

Phil.

Jonathan Larmour wrote:

> Philippe Vandermersch wrote:
>
>> Jifl.
>>
>> I liked your proposal because I do not have to deal with C++ but :
>>
>> 1)
>> fclose( stdout ) failed :
>> ASSERT FAIL: <4>dlmalloc.cxx[765]do_check_chunk() (cyg_uint8 *)p >= 
>> arenabase
>> ASSERT FAIL: <4>dlmalloc.cxx [ 765] do_check_chunk() (cyg_uint8 *)p 
>> >= arenabase
>> TRACE: <4>sched.cxx [ 705] disinherit_priority() }}RETURNING UNSET!
>> TRACE: <4>mutex.cxx [ 447] unlock()
>
>
> Bugger, I forgot about that. fclose() is trying to free stdin, but 
> stdin was not allocated off the heap.
>
>> 2)
>> If I do not close it and do simply : stdout = fdopen(fd_out , "w" ) 
>> seems to succeed but printf does print anything
>
>
> Ah... my guess is that the default buffering mode is full buffering, 
> not line buffering, so you would have to set the buffering mode to 
> _IOLBF with setvbuf().
>
> If it's not that I'm afraid I don't know off-hand what it could be. 
> fdopen() calles fopen_inner() in fopen.cxx, which calls a constructor 
> just like you do below.

>
>> 3)
>> To make it work, I had to do this in C++:
>>
>> Cyg_StdioStream *StdoutStream = new Cyg_StdioStream( fd_out, 
>> Cyg_StdioStream::CYG_STREAM_WRITE, false, false, _IOLBF );
>> if(StdoutStream == NULL) return( ENOMEM );
>> stdout = (FILE *)StdoutStream;
>>
>> It also works for stdin,stderr.
>
>
> That's good. Although if you had a moment, it would be nice if you 
> could have a quick poke around to see why 2) didn't work, and in 
> particular if using setvbuf(stdout, NULL, _IOLBF, BUFSIZ); is all it 
> takes.
>
> Jifl





-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss