Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Jan 2003 15:15:33 -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:  <20030124231533.GA47190@dhcp01.pn.xcllnt.net>
In-Reply-To: <Pine.LNX.4.21.0301242229490.489-100000@tempest.rod.fr>
References:  <20030123234431.GB555@athlon.pn.xcllnt.net> <Pine.LNX.4.21.0301242229490.489-100000@tempest.rod.fr>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 24, 2003 at 10:58:12PM +0100, Rodolphe Ortalo wrote:
> 
> I understand clearly why doing so may be important for serial consoles (or
> possibly other non-display adapters), but wrt most (modern) VGA adapters,
> I have the feeling that discarding the state and switching to some
> advanced mode should be done as soon as possible! :-)

I cannot disagree. Preserving state may range from being crucial
important to totally bollocks. If we switch to some hi-res graphics
mode as part of the low-level console probing and selection, I don't
immediately feel any pain by loosing the info that the loader has
put on the screen. Doing it as part of bus-enumeration and loosing
the output for half the device probes hurts...

State also doesn't have to be visible. State could also mean some
data passed to us through the loader by the firmware. In any case
YMMV.

For the hackery on the ia64 branch I reuse the softc that I
initialize during low-level console probing when I find the
device during bus-enumeration so that I can defer setting cn_dev
to when I actually know the unit number instead of kludging around
the phase ordering problem...

>  What I have to experiment yet is to replace the primary head VGA-only
> boot driver with another instance of the Matrox driver (and get rid
> entirely of the boot drivers), and do this first in the rc scripts.

Yuck :-)

I don't see a problem really. Maybe because I don't understand
what you're trying to achieve, but I don't see how handling of
graphics controllers is different from sound controllers. If
there's no specific driver, but the hardware is VGA compatible,
you use a generic VGA driver.
In any case, you either compile-in the right drivers or you
depend on module loading to achieve some dynamic behaviour.

I categorize the replacement of active drivers during runtime 
without tearing down the "clients" of the driver first as...
as... well, I don't even have a bucket for it. Trash comes
closest :-)

-- 
 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?20030124231533.GA47190>