--PuGuTyElPB9bOcsM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 08, 2007 at 12:44:20PM +0000, Julian Coleman wrote:
> Hi,
>=20
> I've run into a problem trying to get wscons to work on a old sun-4, beca=
use
> of the order in which devices attach.  On newer sparc and sparc64 machine=
s,
> zs* and zstty* attach before the frame buffers but on this sun-4, the fra=
me
> buffer attaches first.
>=20
> The reason that the ordering causes a problem is because both the zstty c=
ode
> and the wscons code set cn_tab->cn_dev.  If the frame buffer (and wsdispl=
ay)
> attach last, then cn_tab->cn_dev is set to the wscons device and all is f=
ine.
> However, if the zstty's attach last, then cn_tab->cn_dev is set to the zs=
tty
> device, and console input/output is broken (the rest of the code is assum=
ing
> wscons).
>=20
> I'm wondering what the best solution for this is.  Two possibilities come=
 to
> mind.  The first is to have some communication between zstty and wscons, =
so
> that zstty_attach() doesn't set cn_tab->cn_dev if wsdisplay_emul_attach()=
 has
> already set it.  The second is to make the sparc MI code not go through t=
he
> zstty framework if we are using wscons and this is the console.

The best solution is to correctly use the MI code. Which is a variant=20
form of your first possibility. :-)

ZS_HWFLAG_CONSOLE_INPUT is in zst_hwflags and says that this is the=20
console.  All of the setting of cn_dev that I can find is based on this=20
flag (and ZS_HWFLAG_CONSOLE_OUTPUT). So if you aren't the console, DON'T=20
SET IT. :-)

That's what these flags mean. So setting them on a tty when it isn't the=20
console is an error.

Also, it seems the sparc code isn't using the console probe code. MD code=
=20
needs a way to figure out what the console is, and to tell MI code. The=20
way this is handled is that struct consdev has a probe routine for each=20
console device. Strictly speaking, it is per driver and minor-number=20
selection is left to the driver. Each consdev gets probed, and the "best=20
one" is selected and its init routine gets called.

The idea is that you should add an entry (struct consdev) for the zsc
code, and an entry for wscons. Or probably the frame buffer. Each will
have a probe routine.  The probe routine fills in cn_pri, which indicates
console priority. There is CN_DEAD, which means "ignore me." There are
then CN_NORMAL, CN_INTERNAL, and CN_REMOTE. Well, there's also CN_NULL,
but ignore it.

CN_NORMAL < CN_INTERNAL < CN_REMOTE. The idea is that the internal=20
graphics display always sets (its) cn_pri CN_INTERNAL. If you have=20
serial console selected, the serial probe routine sets its struct=20
consdev.cn_pri to CN_REMOTE. Otherwise we set it to CN_NORMAL.

So all you have to do is make a probe routine that does this, and have it=
=20
so the place that sets ZS_HWFLAG_CONSOLE is in your zscninit() routine.=20
Then these flags will only be set if you're on a serial console.

Make sense?

Take care,

Bill

--PuGuTyElPB9bOcsM
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFFzAl7Wz+3JHUci9cRAm4+AJ0bqMF3cHvTj8vV5c3awiwVhNWFDgCfd4d6
c1xqStMQoYr7zQXuf8VKRpQ=
=z2RM
-----END PGP SIGNATURE-----

--PuGuTyElPB9bOcsM--