How to redirect stdout to memory buffer?

QNX DEVELOPERS General Programming
1

Hello, is there a way to redirect stdout to a memory buffer?

In our system there are multiple boards running qnx, we want to implement something that allows us to tunnel to any host/board in the system from the master such that all console output of a host can be redirected to the master when a tunnel session is opened. I am thinking if there is a way to redirect the stdout to a memory buffer then I can process/send those buffered output through the inter-board ethernet channel to the master. Is there a better way to do this? Thank you for the advises!

David

2

Hello David,
You may want to redirect output to a file in /dev/shmem.
Example:
ls > /dev/shmem/ls_output.txt

Later open the output file in your application and use as required.
Thanks,
Yuriy

3

From within a C program you can freopen.

4

You could always create a virtual device that would do this. You would redirect all the stdout’s that you might be interested to this device, and it could store the information where ever you want, /dev/shmem for instance. You no doubt need to limit the amount you keep in memory, or eventually you will fill it up. The interface between this driver, and the reader is up to you, QNET, TCP/IP, whatever.

5

In what way does the standard Unix syslogd not fulfill your requirements?

6

I am not very familiar with syslogd, I think that is for logging specific events. My goal is to provide a virtual console to allow users to access to the console of each host from the master board without the need to have a real serial console cable connected to each of every host board in the system. Ok, looks like we can redirect stdout by using freopen(), I have the following more questions:

  1. freopen( const char* filename, const char* mode, FILE* fp ), can its argument “filename” be the shared memory device “/dev/shmem”?

  2. my goal is not just to keep the console output in a file/memory buffer, I will need to send it out continuously as long as there is data pending in the buffer, so I will need to implement some kind of circular buffer to allow stdout to place data in and at the same time the data can be read and sent out continuously by a process. The question is, can the file position be manipulated such that the stdout will place data in the beginning of the file/memory when its position reaches to the max size, so to form a circular buffer?

  3. can the stdout be restored back to its original direction when selected (when the virtual console is closed)?

Or there are other easier ways to do all these?

Thanks a lot.

7

It looks like ditto is what you need. Oh wait it’s not available under QNX6. You may want to look at “screen”. Check this link out: sendreceivereply.wordpress.com/2 … sing-tool/.

Here is how I solved a similar problem. Each machine start a slim down version of photon. It’s setup in such a way that it doesn’t need a graphic card. The advantage is we don’t care about having compatible graphic hardware, the downside is you can’t see that photon session from that machine.

Each program gets to start in it’s own Pterm, that great for debugging because each program can display data or respond to keypress. All these program’s output can be seen at the same time provided a big enough monitor. By setting the pterm scroll back buffer to 1024 line we can go back to see stuff we could have missed otherwise. Other advantages are that many people can, from different computers, access that same photon session at the same time. Because it’s based on TCP/IP it can work across internet.

There is only one way to access this virtual Photon session though, it’s via phindows or phditto and you have to setup tcp/ip, unfortunately phditto doesn’t support qnet.

We have also develop our own version of printf and cout which are able to send the data to both stdout for display and capture the data in a file or any combination. Can even not send any output at all (no display no capture) which save CPU time ( that’s the default state our programs start in). I also added timestamp so that every printf/cout statement is timestamp, which is great if you want to look at the captured file of various processes and know what happened when.

8

I have also thought about the approach of having a special version of printf, looks like that is probably the way to go given no other utilities available currently. Thank you very much Mario and all for the help!

9

Uhhuh, but if you write a custom printf function (using the LD_PRELOAD trick is a great way of getting the subject apps to use this without so much as relinking them), then why can’t you just make syslog() call, and thus automatically get:

  1. timestamping
  2. severity filtering
  3. configuration control of which node the logs get sent to