On Wed, 18 Oct 2000, Greg A. Woods wrote:

# > You must be kidding.  LOG_CONS is there for a reason -- in case syslogd
# > isn't running and output has to go SOMEwhere.
# 
# No, I'm most definitely not kidding.  In fact I've alread made the
# change in my lib/libc/gen/syslog.c -- I just haven't rebuilt the world
# yet.  The comment in the code about not worrying if the console blocks
# incensed me into wiping out the whole mess completely.
# 
# It's either that or flow control on /dev/console has to go away
# permanently, and I'd rather have flow control, thank you very much.

What you COULD do, especially if it's KERNEL logging, is have the
kernel override the current flow on the console, if that's possible.

Yes, I know -- it sounds gross.  It's not an optimal solution.  But think
about it.  If we're a kernel, and we REALLY need to send something THAT
badly, are we gonna respect flow control?

[This would not apply to user-level processes, of course.]

As I said, yeah, it's gross, and it was just a thought.  I doubt
I'd actually implement it as such, but it was worth the thought.

# If syslog(3) can't send packets to the log host, or can't write to disk,
# then the system's hosed anyway (and maybe it should just panic!  :-)

panic: /dev/log blocking on non-blocking write
Sinking disks: 4 2 1 1 sunk!
Rebooting...

# /dev/console is not somewhere where a process can expect to write
# anything unhindered, even if it has appropriate privileges, especially
# in multi-user mode.

"Gee, that's not what I was taught..."

# Flow control, or lack of DCD on a non-local line,
# will stop it in its tracks.
# 
# The day that I hook a printing console back up to a system and rely on
# it for permanent log recording is the only day I'll reneg on this!  :-)

Hey, I wouldn't mind having a DECwriter hooked up to my ttya.

# Now if openlog(3) & syslog(3) had some way to do non-blocking opens and
# writes to /dev/console then things might be a bit different, but I don't
# see an easy way to do that.

Well, you seem to fix this situation below...

# However all is not lost.  If I still really want some log messages to
# appear on /dev/console I can fix syslogd itself so that it does timeouts
# on writes to tty devices and then simply configure whatever messages I
# want to be written on /dev/console!  (BTW it's already annoying when
# you've got syslogd writing duplicate copies of messages that were also
# written by a process that set LOG_CONS.)

Add another level of annoyance when they go to user "root"!
{and before ANYone says "But don't log in as root!", put a sock in it.
 It's MY console, dammit!}

# The next step is to think long and hard about whether or not the kernel
# should block on flow control (or lack of DCD, etc.) when writing its own
# messages to /dev/console.

Heh -- I hadn't even read this far yet.

# My initial impression is that it shouldn't
# ever block -- or at least it should timeout soon enough that other
# things don't get all bound up....

The problem is that if it's a separate tty chip which honors DCD/CTS/RTS
on its own, it's a slightly trickier problem, since the kernel will then
open the floodgates for ALL output which has been waiting on that line.

This would violate the POLS for anyone who, while idiotic enough, was
sitting at the console with XON (XOFF?) or had the hard scroll lock
enabled on the console terminal -- it's a bit hard to convince a glass
tty to forget hardware flow control simply by sending something down
the line.

				--*greywolf;
--
*BSD: Network Power Unleashed.