ethercons updated for -CURRENT

In October of last year, I posted an ethernet console implementation for
FreeBSD 5.x.  I've recently updated that implementation to work with
recent -CURRENT, which included some tweaks to work with network stack
locking, account for changes in our tty infrastructure, etc.  I've posted
the new drop at:

    http://www.watson.org/~robert/freebsd/ethercons/

Specifically, the most recent drop is named:

    20040709-rwatson_ethercons.tgz

It includes a kernel tree patch, three files to add to the kernel source
tree, and a userland tool for logging, connecting, etc.  Building the
userland tool requires that 'src/sys/dev/ethercons/ethercons.h' be
installed in '/usr/include/dev/ethercons', which you get if you build
world with the modified tree, but will have to do by hand otherwise.

When ethercons is compiled into the kernel with "options ETHERCONS", it
will take priority over the regular console.  You can add the following
line to /etc/ttys to hook up a login session:

    ethercons       "/usr/libexec/getty std.9600"   vt100   on secure

Make sure to take note of the security warning below. 

The details remain pretty much the same as before: it's a link layer
protocol that grabs the same unofficial protocol number as the Linux
ethernet console code.  It's not wire compatible because this ethercons
driver supports input and output (the Linux one was output only, so had no
notion of direction).  It supports both low level kernel console ouput
(kernel printf) and a higher level tty interface, letting you run login on
the console.  And as with earlier versions, there is no protocol crypto,
as it assumes a trusted wire.  This is compatible with the expected use
environment of netbooted cluster systems, which is what the implementation
was designed for use with.  (Such systems typically trust the wire for
loading the boot loader, kernel, modules, and sometimes file systems, so
having console I/O on the wire isn't such a big deal).  The other major
limitation is that it relies on the network stack functioning, so can't be
used for very early boot stuff, debugging, etc.  Despite these
limitations, I've found it quite useful for cable reduction, getting a
number of boxes down to two wires: ethernet and power. 

I currently have no explicit plans to commit this to the FreeBSD source
tree, due to reservations about grabbing a non-official protocol number,
lack of a useful standard for ethernet console, etc.  I'm looking at using
PFIL_HOOKS() in the ether_demux() code so that it can plug in with less
disruption (i.e., changes) to the ethernet input code.

Thanks,

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Principal Research Scientist, McAfee Research