On Sat, 29 Mar 1997, Bill Studenmund wrote:

> > Is there a chance I could modify the kernel sources to simply not check
> > for a monitor?  I considered leaving serial console spouting off into an
> > empty port, but then I discovered I needed both of my serial
> > ports...running PPP off the console is a recipe for disaster whenever
> > error messages pop up.
> 
> I actually thought part of the problem was that MacOS didn't want to boot
> w/o a monitor.
> 
I do this all the time with AppleShare actually.  No, it's the kernel.

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

> (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?


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

> My strong suggestion is to just use the paperclip. Messing with the
> console could well break other parts of the kernel. Plus you can't
> swap kernels around easily.
> 
> Shorting the pins makes the Mac think there's a monitor when there's not.
> 

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.


Dan