On Tue, Nov 04, 2008 at 08:12:56PM +0100, Robert Millan wrote:
>
> - Turn the grub_cur_term_{input,output} pointers into lists, so that
> multiple terminals can be "current" at the same time.
>
> - Implement a "magic" input (or output) terminal that can be attached to
> other terminals and reads from (or writes to) more than one of them.
> The advantage of this is that the code doesn't have to be in kernel.
Or a third option, which derives from the second one:
- Move the whole terminal selection code away from kernel, into a module
(e.g. terminal.mod) that manages multiple terminals, and can possibly
enable them simultaneously.
This basicaly would mean:
- There's always a "default" terminal that is built into kernel already.
Before terminal.mod is loaded, the kernel would map generic terminal
functions (grub_getkey(), etc) to this terminal (e.g. using a single
grub_term_{input,output} couple of pointers).
- When loading terminal.mod, it hooks itself by replacing those two
pointers, and implements the whole register / unregister / iterate
enchilada.
- Some special casing would be needed so that the in-kernel terminals
can be part of terminal.mod's scheme.
What I like in this option is that it moves complexity (and code) away from
kernel without removing any functionality from it.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
