Re: [Netconsole-devel] status?

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

Jim Garlick wrote:
> 
> Maybe I'm not explaining this clearly, but it's actually quite simple:
> 
> wc -l *.c
>     395 ec.c            # rewrite of minicom
>     789 elancon.c       # protocol + elan interface
>     542 elantty.c       # tty driver, both callout and "elancon"
>    1726 total
> 

That's not what I would consider simple, and that is with the
infrastructure of a full kernel underneath.  Seriously, it's a pretty
absolute requirement that this can be implemented in assembly in a few
kilobytes, for a pre-booting system.

> > As far as supporting multiple servers, there is a lot you could do but it
> > would all come at considerable cost in client complexity.  Multicasting,
> > for example, requires that the client understands IGMP.  Unicasting to
> > multiple servers would require waiting for ACKs from all of them.
> 
> I dont see unicasting as too big of a problem. Consider that you're taking
> what might normally be throttled through a 9600 baud serial console and
> putting it on a network, albeit shared, with several orders of magnitude more
> bandwidth.  Also, the approach I took was not to ack data as consoles (at
> least serial) are assumed to be lossy (I do ack connect protocol), and to
> actually implement the tty baud rate so senders get throttled down to 38400
> baud or whatever the user chooses to avoid overwhelming the minicom-thing.

Again, more complexity at the client.  If you're willing to accept data
loss, which you obviously are, then why are you worried about "a single
point of failure"; note that the idea of the protocol is that the server
can be rebooted or even replaced, so you could keep a hot spare available
and switch it in place with a simple ifconfig command.
 
> Don't get me wrong - I'm willing to scrap all this and work with the group
> as long as the approach is reasonable.  Just relating my experiences.

Don't get me wrong either; I appreciate your input and I'd like to come
up with something reasonable.  However, I'm very adamant that the client
side of the protocol be simple enough that it can be implemented in the
pre-boot stage.

	-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