Re: [Netconsole-devel] status?

[Jim G. <ga...@ll...>]

On Wed, 21 Feb 2001, H. Peter Anvin wrote:

> > On the architecture, it seems to me like the netcon server approach creates
> > a single point of failure where there doesn't need to be one.  The way
> > I did the elan consoles was I made a range of elancon tty "callout devices"
> > which can be virtually connected to the elancon tty console device on any
> > node via an ioctl.  The client user-space software then just becomes minicom
> > with support for some new tty ioctls (because the connected callout device
> > looks just like /dev/ttyS0), and it is fully peer-to-peer.
> 
> This sounds like an awful lot of complexity.especially for the client. 
> The client really does need to be lean and mean.  To be utterly frank, a
> solution of the complexity level you seem to advocate sounds like you
> might as well go right ahead and just use ssh.

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

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

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.

Jim