Results 1 to 10 of 10
Hello! I'm really not a Linux expert and I'm not using it on day to day basic. At work I'm working on embedded device running Linux. Platform: MIPS32, 4MB Flash, ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 03-15-2007 #1
Redirecting stdout, stderr to pty0?
I'm really not a Linux expert and I'm not using it on day to day basic. At work I'm working on embedded device running Linux.
MIPS32, 4MB Flash, 16MB Ram
OS: Linux 2.4.31
We are connecting to the box via serial port RS-232 cable. I was assigned to write driver for the add-on module which also connects to the embedded device via serial port. Problem is we don't have 2 serial ports on the embedded device, but just one. It's not a problem because I installed telnet daemon and now I'm connecting to the device from the PC by telnet and port is free to be used by add-on module. Problem is that while developing device driver I use a lot of printk function and these printouts go to the serial console!
Can somebody tell me or direct me on how to redirect kernel printouts to the /pts device? I know that pts device is created until new telnet client connects, but would it be possible to compile Linux kernel in such a way that while /dev/pts/0 device is not present all printouts should go to the /dev/null device and if /dev/pts/0 is present, printouts are redirected to the /dev/pts/0 device.
As a matter of fact where do I select where do Linux kernel default stdout, stderr streams go?
Thanks a lot for all the help you can give me.
- 03-15-2007 #2
I have no clue, only a hint.
I think, by default the printk go into the proc file system and before that is an internal buffer that is configurable, too.
But I guess you have already some debug software that redirects this output to the serial port, because that is presumably not the default target, or?
To your question where to configure where stdout actually is, I can't say anything out of my head, but I believe there is something where you can setup the size of this printk output buffer.Bus Error: Passengers dumped. Hech gap yo'q.
- 03-15-2007 #3
- Join Date
- Aug 2006
Try to use another printk priority, you can view them in linux/kernel.h.
- 03-15-2007 #4
Just started looking, but /linux/printk.c in the same directory looks promising, too.Bus Error: Passengers dumped. Hech gap yo'q.
- 03-15-2007 #5Originally Posted by dilbert
Thank you all for other suggestions. It's late at night here so I'll try them all first thing in the morning when I get to work.
- 03-16-2007 #6
I want to elaborate a little more about my specific problem.
I know there are stdin, stdout and stderr streams and also how to redirect them when I'm in the bash console already. I'm writing just one specific driver for the device which connects to the main embedded machine trough serial RS-232 port. If I want this device driver to work properly:
- file descriptor ttyS0 should be free and not taken by the bash
- serial port should not be disturbed with some characters coming from the kernel printouts or other programs printouts
Moreover I don't want to redirect just my printouts, but all the code printouts also from programs and drivers I didn't wrote. So just fixing printk function does not solve my problem fully.
By default, stdout and stderr both appear on "the console", but what exactly is it defined by "the console"? In my embedded device it is serial port ttyS0 on my host it is some other virtual device (pty?) which prints characters on the display directly. Where this redirection is defined? In kernel somewhere? On my host machine nothing goes to the serial port by default, but on the embedded device everything goes there. So, I'm guessing this has to be defined somewhere.
- 03-20-2007 #7
I found solution to my problem. Two actually and both are very simple.
Solution 1.) In the kernel configuration I found the flag CONFIG_SERIAL_CONSOLE. When you are in the kernel configuration (run make menuconfig in the kernel root folder) you go under Character devices ---> Support for console on serial port and turn it off. In my case I also had to make small corrections to the serial driver file because BSP guys did not use define CONFIG_SERIAL_CONSOLE on all places properly and I had undefined references. But if everything is ok, all what is needed is turning off console on serial port and recompiling the kernel. Now /dev/console is not created (it's NULL actually) and all system printouts don't go to the console anymore. Telnet works perfectly and ttyS0 is still there to be used.
Solution 2.) In my case we use boot loader called uBoot. Under many things there, I can also configure "Kernel command line" or specifically variable bootargs variable which placed in the kernel command line when kernel is started. There I added string console=null,115200. It basically says that console device is null. Speed part is not relevant and I didn't try without it. Here also telnet works perfectly and ttyS0 is still there to be used.
I hope this will help someone else looking for the solution to the similar problem.
Thank you everyone for all the help you provided.
- 03-20-2007 #8
Thanks to you overall for passing back what you have found.Bus Error: Passengers dumped. Hech gap yo'q.
- 07-06-2007 #9
- Join Date
- Jul 2007
could you please tell me,how to redirect stdin,stdout,stderr all throuh serial console.what configuration we need to do in kernel and boot loade ( in my case also Uboot loader).
- 07-06-2007 #10
Every boot loader has the ability to pass some boot commands to the Linux kernel. Of course kernel has to know it to interpret it. One of them is
This tells Linux kernel that device for printk function in the kernel is ttyS0 device with baud rate 115200 bps. In your case you may have to use different device (ttyS1,...) and baud rate. But as far as I know this only implies for the Kernel printouts. If you want your application printouts on the serial port you have to start the application in such a way that controlling terminal for that application is ttyS0.
In my embedded system (Busybox, Init, inittab) I added a line to the /etc/inittab
Which basically means that shell is started with ttyS0 as it's controlling terminal. Now every program you start within this shell also has ttyS0 as controlling terminal.
More on this you can read in this articles:
Controlling terminals, serial drivers, line disciplines etc. are quite complex matter, but many resources can be found on the net.