Re: [Netconsole-devel] Getting this show on the road...

[H. P. A. <hp...@tr...>]

li...@ho... wrote:
> 
> Excellent point!  The logging server has to maintain logs and associated
> sequence numbers on stable storage, so it can resume the conversation at
> te right place.  This means that we can't use in-kernel TCP, so...
> 

You can't even require that.  You have to assume that the server
physically was destroyed; you still need to be able to resume
connectivity; obviously data loss.

> >> We are working with minimal boot loaders and the like.  Do you think
> >> they need significant termcap fanciness?  (Are you trying to support
> >> BIOS config screens and the like?)
> 
> > Yes, or "make menuconfig" if you need to rebuild the server kernel, or
> > what have you.
> 
> Um, once you have enough envronment running that you can *run* make
> menuconfig, you have enough that you can just use the regular kernel,
> ssh and the like.

Assuming it's safe for you to enable it.
 
> But I understand the disconnect now.  I was thinking /var/log/kern.log
> and you were thinking /dev/tty1.
> 
> You want to export the keyboard and screen across the network for
> everything.

Yes, way, way early before the kernel even boots.
 
> One point that raises is that you want to be able to connect even if the
> headless box has spewed so much that its buffers have overrun and the server
> has lost sync.  Does the headless box have to keep track a virtual
> screen that can be downloaded at will?  Or is it okay to say that it might
> get corrupted and require a ^L to fix?

I think so.
 
> When I said "crashing problems", I meant "things that print a message to
> the screen and lock the machine."
> 
> In *this* case, a big issue will be sharing access to the ethernet with
> the OS driver.  One way to do it, that I have used for serial ports is
> to maintain an interrupt-safe buffer of data to send, which normally
> the low-level code queues and the OS device drivers sends out.
> 
> But if the buffer overruns, the low-level code leaves interrupts off
> and runs a special polling driver to push the buffer out synchronously,
> on the asumption that the OS is hosed.
> 
> I don't know if this is amenable to ethernets.  How *are* we going to
> do this?  Require a dedicated NIC for the console?  It's actually not
> unreasonable given the price of NICs and hub ports these days.

Most NICs these days require a lot of machinery to work at all.  I'm sure
you can isolate it, but it almost certainly requires a lot of work.  I
think there is a completely different project out there that deals with
Linux crash dumping (postmortem debugging.)  It's a fundamentally
different problem, and personally I'd like to consider that out of scope.

One thing worth considering is whether or not there should be a separate
log stream in addition to the two-way data stream, though.  A log stream
would at least avoid the "I can't log into the server console because of
all the spewage" problem.

	-hpa

-- 
<hp...@tr...> at work, <hp...@zy...> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt