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

[<li...@ho...>]

> Actually, the biggest reason *not* to use TCP is what happens when the
> server dies, and then is restarted.  It is utterly imperative that it has
> no effect on the clients, but you should still resume the connection
> (even though you have probably lost data) which is unachievable using TCP
> on stock Unix systems.

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...

>> 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.


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.


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?

> That is *one* application.  The much more important application is to
> *manage* a headless machine in a machine room somewhere.  The network is
> a really bad choice for the crash dump application: there are way too
> many things that can cause that to die.

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.