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

On Tue, Oct 28, 2003 at 04:19:51PM +0000, David Laight wrote:
> I'm actually not sure how well the code works with serial consoles.
> In order to process Fn it always looks at the raw keycode and not the ACS=
II
> value (both are returned by the bios call used).
>=20
> It could be changed to use the ASCII value and then A.. (or maybe a..)
> to load the bootstrap from a different disk.  But that could not be
> documented in the bootloader output.
> Additionally using a.. would break badly if you have an 'azerty' keyboard
> (F1.. and 1.. are safe because they are always adjacent keycodes).
>=20
> Switching the disks to be 1.. and the partitions to be F1.. will actually
> give problems with the menu - it will take a few more bytes of code to
> generate (you really don't want to know some of the details!)

Is the menu generated, or static? I thought it was static, and you use=20
fdisk -b to update it. If it isn't, would it be easy to make it static?

If it's dynamic, I think it would also be fine to emit a space before the
numbers if the partitions are still '1'. So that way the added code just
loads a constant and prints it. While we'd still need the space for the
constant and the call to the BIOS, we wouldn't need any conditionals.

While it would be nice to have (the option of) F1 back, F1 vs 1 isn't=20
something that will change on the fly, so we can cut corners to keep=20
everything fitting in the needed space.

Take care,

Bill

--+1TulI7fc0PCHNy3
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/oLF6Wz+3JHUci9cRAsQWAKCMSrL4tWVLl3dzqGF8K6o4ByyUcACfV0Ne
xSh+zW5Flei5zLcDK16swpQ=
=D2dJ
-----END PGP SIGNATURE-----

--+1TulI7fc0PCHNy3--