> > Also, if you modify /etc/syslogd.conf, you can make it so NO messages
> > normally get sent to the console. I'd still suggest a serial console,
> > but you should be able to keep ppp up on it. W/ syslogd changed,
> > the only thing which will put up error messages is the innards of the
> > kernel itself, when something panics.
>
> Hmm.  So if I compile a kernel with a large enough ZS ring size- we should
> consider standardizing it a bit larger than 512,  25mHz just can't take
> 28.8 at that speed.  Any opinions? - and modify syslogd.conf I should be
> OK?   HMmmmm.

The 1.2 kernel had a 2K ring size.

> > (There are two ways the console gets accessed. One is via special console
> > subroutines, which are used during autoconfig, and when the kernel
> > panics. The other is via the device over which the console sits. Changing
> > /etc/syslogd.conf should take care of the letter. symlinking /dev/console
> > to /dev/null should do it too).
> > 
> So basically replacing /dev/console with a copy of /dev/null.  But what
> about /dev/ttye0 which the getty runs on?  Do I need to link this to
> dev/null too?

Two things: you can just turn off the getty for ttye0, and the ite has
been set up so that if there's no screen, opening ttye0 generates an
error.

> > > So I would like to make a mutilated kernel that would simply discard all
> > > video without redirecting to serial console- a true headless kernel.
> > > Any ideas on this or the effect of shorting the pins?
> > 
> > No. The kernel goes looking for console devices, and picks the highest
> > priority one. The priorities are (the names are off):
> > 
> > CN_REMOTE
> > CN_INTERNAL
> > CN_NORMAL
> > CN_DEAD
> > 
> > No "CN_DEAD" console device is ever chosen. Normally the serial ports
> > show up as a "CN_NORMAL" device, and the video as an "CN_INTERNAL". As
> > "CN_INTERNAL" is higher priority, the video's chosen. If you choose
> > serial console, the serial console line is set to "CN_REMOTE". Thus it
> > is chosen.
> > 
> > If you hack out the video stuff, then the serial port will become the
> > console.
> > 
> Actually, if you look in cninit.c,  it says:
> if (cn_tab == NULL) {
> /* No console?  We can handle that. */
> 
> And all kernel console routines check for a null console.  But this isn't
> an issue on macs; if the ite doesn't find a console it causes a kernel
> panic so we never get there.

There's a table in mac68k/mac68k/conf.c called constab[] which lists
the possable console devices. These items are type "struct consdev".
One of the entries is the probe routine for the console device. That's
how itecnprobe gets called. I gather you're refering to the panic
in itecnprobe. That panic only occurs if you've deleted the ite
from the known devices w/o deleting the reference to itecnprobe.
As well it should. Or are you refering to a different panic (the
only other one in the 1.2 ite.c is about bit depths)?

When I said the serial ports would become the console (above), I
meant that if you just ripped the video stuff out, there'd still
be the zscnprobe call, and it would return a console device which
could become the console, even w/o serial console checked.

> But again - every so often I need to use a console on this thing.  I don't
> want to short out the pins unless I know my VGA monitor will still work
> without them.

I'm confused. You're talking about ripping out the video console
support. Then why do you care about EVER hooking up a monitor?

What video mode is the VGA monitor running in? Just go to Radio Shack,
buy a 15 pin D connector, and solder together the sense pins for that
monitor. The Apple tech notes should say what pins sense as what
monitors.

Take care,

Bill