Date: Thu, 23 Jan 2003 22:58:48 +0100 From: Nicolas Souchu <nsouch@free.fr> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: arch@FreeBSD.ORG Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030123225848.A12164@armor.fastether> In-Reply-To: <20030123063040.GA16266@cirb503493.alcatel.com.au>; from peterjeremy@optushome.com.au on Thu, Jan 23, 2003 at 05:30:40PM %2B1100 References: <20030122010246.52789.qmail@web13404.mail.yahoo.com> <1043236066.28124.6.camel@builder02.qubesoft.com> <20030122223626.B8449@armor.fastether> <20030123063040.GA16266@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 23, 2003 at 05:30:40PM +1100, Peter Jeremy wrote: > On Wed, Jan 22, 2003 at 10:36:26PM +0100, Nicolas Souchu wrote: > >On Wed, Jan 22, 2003 at 11:47:46AM +0000, Doug Rabson wrote: > >> The main sticking point for this stuff is that console is needed before > >> the device tree is probed. > > > >The approach of KGI is to provide a very basic/minimal driver for console boot > >that can be overlaped later by fully probed graphic board drivers. This is > >somehow how VGA adapter is organized, with the video_switch used immediatly > >and later the vga_isa.c glue-code for newbus full attachement. [...] > > The existing console code gets around this by being excessively chummy > with the hardware (and I gather KGI works the same way). The downside > is that this is very non-portable - you need separate low-level console > code for each architecture and for each different possible console > device. Depends on what the console code is for you. syscons currently works on TGA Alpha adapters which is totally non ISA/VGA hardware. The hardwired code is part of dev/fb, not dev/syscons. We have to separate console implementation from rendering (fb, fonts) and even video drivers. I have some good understanding of Doug's newbus and newbus is more a driver than a console issue. The fact is that if you want to display the console output, you need some rendering and a graphic/text driver and yes the later makes assumption on the OS bus/io architecture. If you consider PCI, the bus standard is simple and detailed enough to allow any code to browse it, detect some hardware and perform basic I/O to setup a linear framebuffer and set a mode. This is what I would call a minimal/basic driver. Of course, when the OS boots the hardware has to be reprobed and this minimal driver has to be substituted by a soft one using the OS resources/methods. KGI has its own bus abstraction layer (far more simple than FreeBSD one's) that should allow to write simple I/O methods for PCI on different architectures. Extending this bus layer to accept other kind of busses is part of the TODOs... -- Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030123225848.A12164>