--Signature_Mon__23_May_2005_13_39_17_-0400__apmTf+Mm=e.UMJJ
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hello,

> > And wouldn't uint16_t ( or probably wchar_t ) be enough for
> > characters?
> > So far we don't use more than 8bit anyway.
>=20
> Well, isn't wchar_t 32-bits on most architectures (36 on pdp10)? :-)

umm... for some reason I assumed they were 16 bit. I'm pretty sure on NT
they are. Anyway - do we need more than 16bit per character?

> Also, are the attributes stored in-line with the caracters, or in a=20
> separate array?

Depends on the driver - ofb for instance doesn't store them at all.
machfb, cgsix and pnozz store u_int because that's what we get in
putchar().

> i.e. do we have struct charinfo {wchar_t char, attr}=20
> screensworth[x*y]; or do we have wchar_t chars[x*y], attrs[x*y]. If we

> have the former, it's better to just use whatever size is used for the

The drivers mentioned above just allocate one big block of
num_chars*(sizeof(long)+sizeof(u_int)) for each virtual console, store
the attributes first in one chunk and characters behind because long may
need bigger alignment than the characters themselves.=20
Yes, an odd number of characters is unlikely but not impossible ;)
Mixing them would waste 4 more bytes per character on sparc64.

have fun
Michael

--Signature_Mon__23_May_2005_13_39_17_-0400__apmTf+Mm=e.UMJJ
Content-Type: application/pgp-signature

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

iQEVAwUBQpIVRcpnzkX8Yg2nAQLZpQf/fum9UIo/sfxjvkxRl1Hf7wYlyu6krnMh
P6qTeIfZayQ6z43U10pvTuSsUwUW1Mg/WjMPNC8FT9E9aWOP1LOlLR4/f4eDMwk5
80cXgG/KOtQvh6eG74NtMbNFA1tByM4ajemIEkIGPpAxWTJRVennUFmg9lIyXw66
bM1Ek0DZr+2S9t6weQ7gnhX96mph9fk8XxT/P4AdzWpMoneYT/fLwIuOsy56mzL/
Jl3UfmqWE6WvSJ4TPasuX7OITTS+pyqSKfkIPWtOYFR9q451TnlJxZrvFEOz0GZx
+HUO+wLScfWbReU27pwBzWi7jRKccUpCAV6IpaHenZOQt7+vYnhssw==
=7V4D
-----END PGP SIGNATURE-----

--Signature_Mon__23_May_2005_13_39_17_-0400__apmTf+Mm=e.UMJJ--