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

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

li...@ho... wrote:
> 
> > Okay, let's look at the basic design of this puppy.  I don't
> > so much mean protocol details and the be or not be of security
> > (which I'd rather wait with until we have a prototype) but more
> > the general architecture.
> 
> Security can be postponed a bit, but a bit of protocol design would
> be relevant to the architecture.
> 
> The most important piece of architecture is how it fits in to the
> "client", as you have called it, the machine containing the netcon stub.
> The protocol is a big enough part of that to be an "architecture" issue.
> 
> Your UA/server/client (although I'd like a different word than "client",
> maybe debugger-style "target"?) design makes sense, particularly if the
> netcon protocol will perform poorly over a long-haul link.
> 
> > Although the current assumption is that Netcon Protocol is a UDP
> > protocol, it will provide a logical bidirectional stream capability.
> 
> Once you're supporting a bidirectional stream, think hard about
> a stripped-down TCP.  The only thing you might be able to do better
> with a hand-rolled one is pass state between boot loader stages.
> 

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.

Some multiport serial cards have been known to glitch the TxD line during
initialization.  The system at the other end tends to interpret that as a
BREAK.  I have seen what happens if the multiport serial card happens to
be hooked up to a rackful of Suns.  We most emphatically do NOT want the
equivalent problem.

> > I really want to define a specific terminal emulation for this protocol.
> > I definitely believe we do need more than a basic terminal, and having a
> > specific terminal emulation is key.  The only logical such terminal is
> > some ANSI/DEC VT subset.  Character set is yet another issue; I don't
> > think I have the guts to mandate UTF-8 over this stream.
> 
> Ack!  Pfft!  Where did *this* idea come from?
> 
> To put it more moderately, please explain why that is other than a Bad Idea.
> 
> You said you want the server to do logging.  ANSI cursor control seems
> like it would make that difficult, at least.
> 

Hardly so.  I wrote that code myself a long time ago -- it's utterly
trivial.

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

> 
> I was thinking of something of the sophistication of Sun's serial console.
> The idea is to be able to debug booting and crashing problems in a
> headless machine in a machine room somewhere.
> 
> If not, could we have a little discussion of intended applications?
> 

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.

	-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