From owner-freebsd-current  Sun Jul 20 09:30:02 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id JAA22776
          for current-outgoing; Sun, 20 Jul 1997 09:30:02 -0700 (PDT)
Received: from pandora.hh.kew.com (root@kendra.ne.mediaone.net [24.128.53.73])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA22741
          for <current@FreeBSD.ORG>; Sun, 20 Jul 1997 09:29:58 -0700 (PDT)
Received: from sonata (sonata.hh.kew.com [192.195.203.135])
	by pandora.hh.kew.com (8.8.5/8.8.5) with SMTP id MAA03754;
	Sun, 20 Jul 1997 12:29:55 -0400 (EDT)
Message-ID: <33D23D02.80@kew.com>
Date: Sun, 20 Jul 1997 12:29:54 -0400
From: Drew Derbyshire <ahd@kew.com>
Reply-To: ahd@kew.com
Organization: Kendra Electronic Wonderworks
X-Mailer: Mozilla 3.01GoldC-MOENE  (WinNT; U)
MIME-Version: 1.0
To: current@FreeBSD.ORG
CC: bde@zeta.org.au
Subject: Re: current-digest V3 #104
References: <199707192051.NAA11743@hub.freebsd.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> From: Bruce Evans <bde@zeta.org.au>
> Date: Sat, 19 Jul 1997 19:06:24 +1000 
> Subject: Re: Serial console in -current
>
> >Understood.  How would you propose to handle the case where none of the
> >serial devices are marked as console but RB_SERIAL is set?  The 
> >current behaviour is undeniably bogus, not to mention annoying. 8) 

> Same as if there are no serial devices configured - tell the user to
> not use a silly configuration :-).

While this may be desirable from purist point of view, I must disagree
it for pragmatic reasons.

First, the historical behavior not requiring a special flag is
reasonable, understood, and consistent with other headless
configurations.  (At least my SPARC did the Right Thing and found the
first serial port when I tried this a year or so ago.)

Second, and more importantly, if I have a urgent need to switch to a
serial console and I don't have time to regen or extensively reconfigure
the kernel, I don't want to be blocked by the kernel refusing to use a
reasonable default.   (One of my systems doesn't have a normally have
monitor -- blindly feeding a boot -h is doable, a kernel reconfig is
_not_.)

Certainly, allowing the flag to make the behavior tunable is a good
thing, but don't break things given how important a console can be to
fixing a system which has other boot problems.

-ahd-