2008-08-06 19:23:09     Obtaining exclusive lock for serial port output

Document created by Aaronwu Employee on Aug 8, 2013
Version 1Show Document
  • View in full screen mode

2008-08-06 19:23:09     Obtaining exclusive lock for serial port output

Steve Strobel (UNITED STATES)

Message: 60056   

 

I am using a typical /etc/rc file that starts several programs in the background (by starting them with a & suffix).  From the "root:~>" prompt I (actually a PC program) sometimes run a management program in the foreground that prints a large (200KB) set of data followed by a CRC checksum.  Occasionally the kernel or one of the programs running in the background will print a message that gets interjected in the middle of that set of data, corrupting it and preventing the CRC from matching.  I would like to make the management program obtain some kind of exclusive access to the serial port for a time so the kernel and other programs cannot corrupt the output.  Suggestions?

 

Steve

QuoteReplyEditDelete

 

 

2008-08-06 22:55:52     Re: Obtaining exclusive lock for serial port output

Yi Li (CHINA)

Message: 60061   

 

You can change the kernel boot option "console=" to some other device, instead of using serial port.

 

QuoteReplyEditDelete

 

 

2008-08-07 12:17:32     Re: Obtaining exclusive lock for serial port output

Steve Strobel (UNITED STATES)

Message: 60107   

 

Thanks for the response.  I am not sure I understand how changing the console to a different device would help.  To run the management program, I need access to the root:~> prompt, which would now be accessible through the new device.  If I ran the management program from that new device, it would have the same problem I have now.

 

What would help is having two consoles, one that receives all of the error and status messages and one that just gives a root:~> prompt from which I can run the management program.  I have two serial ports.  Would that be difficult to set up?  The two-console solution wouldn't be as nice as a method to gain exclusive access for a time, as I normally want to see the status and error messages (such as when a USB drive is plugged in or unplugged, or if the kernel prints an error message), and I won't always have the ability to connect to both serial ports.  So I would still be interested in getting exclusive access to the serial port if there is a way to do that.

 

Steve

QuoteReplyEditDelete

 

 

2008-08-07 13:55:12     Re: Obtaining exclusive lock for serial port output

Robin Getz (UNITED STATES)

Message: 60113   

 

Steve:

 

It really depends on what you are trying to do (seperate a different userspace app, or a kernel messages).

 

For kernel messages - things are described at:

 

https://docs.blackfin.uclinux.org/doku.php?id=silent_booting

 

For seperating userspace - stdout is stdout.

 

start your app with " 1> /dev/null 2>/dev/null" - or point it to a file.

 

-Robin

QuoteReplyEditDelete

 

 

2008-08-08 11:24:48     Re: Obtaining exclusive lock for serial port output

Steve Strobel (UNITED STATES)

Message: 60179   

 

I think that starting all of the background programs with stdout and stderr redirected to /dev/null would work pretty well.  Thanks for the suggestion.  I don't get many kernel messages, so I could easily live with them.

 

It would be really nice to be able to switch the messages on and off, so they could be used for troubleshooting when not running the management application.  Is there any way to redirect them to something that could be steered to either /dev/null or to the serial port?  Can a simlink be used for something like that?  Could it be changed on the fly, or only before each program was started?

 

Another option might be to redirect stdout and stderr to fifos.  When the management program was not running, another background task could be started that would read from the fifos and print the messages to stdout and stderr.  Any idea if that would work?  Would those programs block if the fifos got full, or would the overflow just get discarded?

 

Thanks for the help,

 

Steve

QuoteReplyEditDelete

 

 

2008-08-08 12:03:40     Re: Obtaining exclusive lock for serial port output

Mike Frysinger (UNITED STATES)

Message: 60180   

 

the document Robin pointed out shows you how to control the message flow to the console.  note that this doesnt turn messages "on and off", just which ones get sent to the console.  all messages are retained in the kernel log buffer and can be retrieved via normal methods (such as `dmesg`).

 

a symlink will accomplish nothing with the kernel as that is not how it resolves device names.

 

changing a symlink will not get the behavior you want with userspace programs as each one will open the symlink once (during start) and keep that file open until the application quits ... mucking with the symlink after the program has started will not affect the program in any way.

 

you can easily create a fifo (read `mkfifo`) and send all userspace application output to that ... but that wont affect the kernel at all ...

QuoteReplyEditDelete

 

 

2008-08-08 18:42:02     Re: Obtaining exclusive lock for serial port output

Steve Strobel (UNITED STATES)

Message: 60194   

 

I think I will try a fifo and see what happens when it gets full.  If that causes problems, I might have to fall back to /dev/null.

 

Thanks for the help,

 

Steve

Attachments

    Outcomes