[Top][All Lists]

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

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

From: Yoshinori K. Okuji
Subject: Re: [RFC] Multi-terminal support (Re: [PATCH] terminal split)
Date: Sat, 22 Nov 2008 18:42:54 +0100
User-agent: KMail/1.9.9

On Friday 07 November 2008 20:26:32 Robert Millan wrote:
> 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.

My feeling is that it is better to include all the functionality in the kernel 
itself, because the users of the terminal API would have to be aware of the 
presence of multiple terminals in some cases, anyway.

When you just print out a string, you can treat all kinds of terminals as dumb 
terminals, so it is very simple. No need to care about their differences.

However, whenever you want to do more than that, you must control each 
terminal differently. In particular, the menu code. The menu interface may 
not be uniform with all terminals. A terminal might have the size 80x25. 
Another might have 120x40. This is more complex with graphical terminals.

I like the idea that GRUB displays the user interface simultaneously. But this 
requires a lot of refactoring. Probably, the menu code will have to iterate 
all terminals explicitly, and make actions differently for each terminal, 
based on the capabilities. With the menu editor, how should the cursor be 
managed? We need to think a lot.


reply via email to

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