Hmmm interesting proposition.
I am slightly guessing here, but 2 suggestions (and this is based on my experience with Slackware, with which I am by no means an expert):
"The Console" in my case would be devices tty1 to tty12,which are 'virtual consoles', depending on which console it was in which my system started running. With my system, the default device is tty0, with the screen output appearing on virtual-terminal 6, where root ends up before starting the X environent for me, the user, on tty7. This configuration is determined by various system files located in both the /etc directory, and in the etc/X11 directory (X11 is for the X graphical server).
So yes, the default, or system console in your case would also likely be defined as a default device somewhere in the system config/startup files or scripts which are run or parsed when your system boots.
As for redrecting ALL output from ALL running apps, services, drivers, etc, well, that may not be the simplest thing, however there is typically a daemon running called sysklogd, which is the system logger. The purpose of this is to 'catch' all messages that the system and/or kernel produce, and direct them somewhere.
In my case, for example, messages from the kernel all go to a file I made called 'kern-info'. All mail messages go to user(s), and all emergency messages go to all users.
As I mentioned, I also set up the sysklogd to redirect ALL messages of ANY type to tty12.
Now, that said, assuming your system has a similar system-logger daemon, it will have a configuration file somewhere, which tells the logger what to do with the various types of messages it catches. If this is the case, then the system logger is what you will want to configure, to send NONE of ANY messages to 'the console', but to send ALL of ALL messages to the device you want them sent to.
The kernel does have a bit to do with the verbosity and source of some amount of log and debug messages; many options within the kernel can be configured to be more or less verbose; many drivers and other system daemons and drivers can also be configured with varying levels of verbosity, and can also likely be configured to send their messages to other devices.
I think what you need is one of 2 solutions:
a) Investigate the system-logger daemon/method of your system, and see what options you can start it up with to work towards your goal of having ALL system messages directed to where you want.
b) running a daemon either alongside of, or instead of, the 'sysklogd daemon' default systemlogger, and set up this logger to your own personal desires.
Finally, as to determining exactly what 'the console' is on your machine, if you are logged in as root, type the letter 'w' at the command line, and it will tell you who is logged on, and where they are.
When I run it on my system, it tells me that I (user Sasha) is the only user, and is logged onto tty0. Since I know that my X server graphical environment is running on 'Virtual Terminal 7' (vt7, which is one of the tty1 - tty12 that I mentioned above) I am going to guess that in my case, 'the console' by default is tty0. Perhaps this is the default case for most systems? I'm not sure. But try typing the 'w' as root, from your default console, and see what it says for which console you are in.
At this point, you would atleast know 'what' you have to redirect from/to, and in the case of stuff that you wish to keep AWAY from the serial port, the same principle applies: determine which logging method is being used, and if by default it is or isn't sending stuff to where you don't/do want it to go, change the logger.
(Golly, I hope I haven't gotten you as confused by now as I think I am.. This little text area I'm typing in just isn't doing it
LOL.. The short answer: "1)Yes, I'd say it is defined mostly or completely in configuration file(s). 2) I don't believe you can configure where stdin, stdout and stderr go from within the kernel configuration. and 3) I don't believe it is possible to completely 'quiet the kernel', only redirect the noise."
Best of luck!! If you need me to confuse you more, please, just ask
, but really, I hope all this helps you even a little bit!
PS - I'd also venture a guess that whatever method is used to connect to the server initially, in your case via rs232, that device may end up being 'the console', so you *might* have no way around the RS232 being the receiver of kernel messages.