Date: Thu, 23 Jan 2003 15:44:31 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Rodolphe Ortalo <ortalo@laas.fr> Cc: Nicolas Souchu <nsouch@free.fr>, arch@freebsd.org Subject: Re: the mythical syscons redesign document ( was Re: Porting wscons ) Message-ID: <20030123234431.GB555@athlon.pn.xcllnt.net> In-Reply-To: <Pine.LNX.4.21.0301232326380.485-100000@tempest.rod.fr> References: <20030123071232.GA80532@dhcp01.pn.xcllnt.net> <Pine.LNX.4.21.0301232326380.485-100000@tempest.rod.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 23, 2003 at 11:53:55PM +0100, Rodolphe Ortalo wrote: > > > The approach I took on the ia64 branch is to have a xxx_machdep.c in > > sys/$ARCH/$ARCH for every device xxx that can be a low level console. > > In the file xxx_machdep.c you do whatever MD specific thing you need > > to do to construct a tag and handle for use by the MI code for device > > xxx. When bus enumeration happens, you compare the tag and handle of > > the low-level console with the tag and handle of the device that's > > being probed if you want to know if the device that's being probed is > > the console or not (you don't want to reset the device if it's the > > console for example). > > Why do you want to take so much care wrt the initial boot device? > If you want to preserve the console display across the switch to a new > display driver isn't it possible to do this at a higher level? E.g.: save > the console output somewhere, close() the boot driver, open the new > driver(), set an adequate text (or text-on-graphic) mode, restore the > console output, and then proceed. > Are there other reasons that motivated a more careful approach? Not all low-level consoles are (graphical) display adapters. If the low-level console is a serial interface, you need to preserve the communication settings. In general though I like to take the approach that the low-level console has done some work, possibly non-trivial, to get the state/information it currently has and it seems wasteful to destroy that state simply because we run into that device during bus enumeration and we then have the resources available to use the device to its fullest potential, but end up not doing that. So, unless there's a good reason not to, preserving state can only proof beneficial. I realize it's mostly subjective. I think you should have the mechanism to allow preserving state, so that you have the freedom to make use of it or not... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net 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?20030123234431.GB555>