From owner-freebsd-sparc64@FreeBSD.ORG  Tue Mar 16 19:20:35 2004
Return-Path: <owner-freebsd-sparc64@FreeBSD.ORG>
Delivered-To: freebsd-sparc64@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 2E11216A4CF
	for <freebsd-sparc64@freebsd.org>;
	Tue, 16 Mar 2004 19:20:35 -0800 (PST)
Received: from liberty.onthenet.com.au (liberty.OntheNet.com.au
	[203.22.124.10])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 8266243D48
	for <freebsd-sparc64@freebsd.org>;
	Tue, 16 Mar 2004 19:20:34 -0800 (PST)
	(envelope-from grehan@freebsd.org)
Received: from freebsd.org (CPE-30-219.dsl.onthenet.net [203.144.30.219])
	i2H3KMZG034157;	Wed, 17 Mar 2004 13:20:23 +1000 (EST)
	(envelope-from grehan@freebsd.org)
Message-ID: <4057C4B4.2030305@freebsd.org>
Date: Wed, 17 Mar 2004 13:23:32 +1000
From: Peter Grehan <grehan@freebsd.org>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030524
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Marcel Moolenaar <marcel@xcllnt.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
cc: Ken Smith <kensmith@cse.Buffalo.EDU>
cc: freebsd-sparc64@freebsd.org
Subject: Re: Console patch part II...
X-BeenThere: freebsd-sparc64@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Porting FreeBSD to the Sparc <freebsd-sparc64.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64>,
	<mailto:freebsd-sparc64-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-sparc64>
List-Post: <mailto:freebsd-sparc64@freebsd.org>
List-Help: <mailto:freebsd-sparc64-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64>,
	<mailto:freebsd-sparc64-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Mar 2004 03:20:35 -0000

 >Fix syscons.

  As I mentioned when I worked around this problem on PPC, it's
easier said than done.

  The problem is the SC_STAT macro which relies on having
an allocated cdev. This macro is used all over the place,
even during the boot sequence, so it's difficult to delay
the creation of the cdev until a point where it is safe,
like 'correct' console drivers do. A nasty one to fix.

later,

Peter.