--8S1fMsFYqgBC+BN/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Feb 20, 2008 at 01:44:42PM -0800, Marcel Moolenaar wrote:
>control over everything. On top of that, we can't use any
>code in the loader from the kernel, so whatever support we
>add, we need to add to the kernel too.
We can't re-use the same executable bytes but, with care, we
should be able to reuse some of the source code.
> At least, I think
>it's lame to support fancy graphics in the loader and then
>not support at least the same in the kernel. If you raise
>the bar for the loader, you also have to raise it for the
>kernel. How else would the kernel be able to use the console?
We already have splash(4) and can support a character-mode interface
to a graphics-mode adapter. IMHO, the major reason for having
graphics support in the kernel is KGI/GGI - which offers the possibility
of being able to use DDB from X.
>So, the question is: how important is it for the user to
>be able to tweak it all.
For GGI, quite important because the kernel is defining the X
resolution. Whether that needs to be the same as the resolution used
by the boot loader is a different question.
--=20
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
--8S1fMsFYqgBC+BN/
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
iD8DBQFHvT1x/opHv/APuIcRAhnrAKDED6Q1woXR1W1lV9cy2b7ivutEZgCeI3pm
b7eQ5Z0ZYrzCZ/gt1J8hCpM=
=zjEN
-----END PGP SIGNATURE-----
--8S1fMsFYqgBC+BN/--