grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RFC] Multi-terminal support (Re: [PATCH] terminal split)


From: Robert Millan
Subject: [RFC] Multi-terminal support (Re: [PATCH] terminal split)
Date: Fri, 7 Nov 2008 20:26:32 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

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."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]