Re: [Netconsole-devel] status?

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

Sounds great.  So I take it a rough design has already been proposed?
I'd like to get my $0.02 in on the requirements:

1. well defined, simple interface for the communication layer so ethernets, 
   CAN (I maintain the Meiko CS/2 linux port), and cluster interconnects can 
   plug in.

2. in my world of clusters, the network is assumed to be physically
   secure and root on any node is equiv to root on any other node.  Ideally,
   console mangement would be peer-to-peer and root-only within that space.
   Outside of that space, access should be unavailable or sufficiently 
   protected.

3. ability to "broadcast" to some set of consoles, i.e. you open a display 
   full of console windows talking to various nodes, and you have a separate 
   window where everything typed is sent to all those nodes' consoles

4. ability to force a panic remotely, esp when node is half way hung, like
   interrupts work but processes don't run
 
5. console "stealing" protocol, i.e. joe has a console open and goes home,
   sue should be able to tell joe has the console open and usurp it, causing
   joe's session to report sue as the culprit.

6. I already mentioned the problem of preserving connect state across a reboot.

I have 2-5 covered with my elan implementation, and I'd really like to get
#1 defined so I can take advantage of anything this group comes up with.
#6 is maybe a linuxbios issue - allocating bits of the system NVRAM.

I also have a minicom-like client program that manages the sessions (including
"stealing" and broadcasts) and a separate console logging/session management 
system for serial consoles (lots of serial consoles connected to a digiboard).
I had planned to put these all together in one package so you get the same 
interface no matter how the consoles are connected.

Do you think some collaboration is possible here?

Thanks,

Jim

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

> Jim Garlick wrote:
> > 
> > Hi,
> > 
> > Anyone doing any work on this project?
> > 
> > A colleague pointed the sourceforge project out to me.  I have some code
> > already developed that enables me to do linux consoles over the Quadrics
> > Elan cluster interconnect, and I had planned to extend this to include
> > ethernet if I could figure out how to do it in a non-hardware-specific way.
> > 
> > On the elan, I can run a getty, capture printk's, even shutdown to single
> > user and come back up again.  What I can't currently do is store the
> > identity of the node that currently is connected to the console across a
> > reboot, or of course, to talk to the BIOS (unless the BIOS is LinuxBIOS!)
> > 
> > Ultimately I would like to have this work over ethernet on an API CS20 node,
> > which has ethernet wake-on-lan for power management and can do LinuxBIOS.
> > In theory I could then dispense with serial consoles in a large cluster of
> > CS20's.
> > 
> 
> Getting LinuxBIOS to support Netcon would be a big win.  That shouldn't
> even be that hard.  To make an unmodified BIOS support netcon probably
> would involve a hacked network card boot PROM that intercepts INT 10h;
> since a lot of network cards have EEPROM these days it might actually be
> doable (perhaps using NILO or somesuch.)
> 
> Anyway, Jim, to give you a primer: we're talking about using UDP,
> although a raw Ethernet option might be doable (the biggest problem with
> that is that the packet limit is much smaller.)  You do, of course, need
> an Ethernet card specific driver either way.
> 
> I am planning to add support for Netcon in the PXELINUX boot loader,
> since it has the PXE stack available.
> 
> 	-hpa
> 
> 
> P.S. I have complained about the archive for this list not working.  I
> hope it can get fixed.
> 
> -- 
> <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
>