From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1L3wVa-0001nT-Ed for mharc-grub-devel@gnu.org; Sat, 22 Nov 2008 12:43:02 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L3wVY-0001lN-Ja for grub-devel@gnu.org; Sat, 22 Nov 2008 12:43:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L3wVX-0001kF-OD for grub-devel@gnu.org; Sat, 22 Nov 2008 12:43:00 -0500 Received: from [199.232.76.173] (port=52917 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L3wVX-0001kA-MH for grub-devel@gnu.org; Sat, 22 Nov 2008 12:42:59 -0500 Received: from ns39764.ovh.net ([91.121.25.85]:55195 helo=nexedi.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L3wVX-0002BS-Aq for grub-devel@gnu.org; Sat, 22 Nov 2008 12:42:59 -0500 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id 25D383DA32 for ; Sat, 22 Nov 2008 18:42:56 +0100 (CET) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Sat, 22 Nov 2008 18:42:54 +0100 User-Agent: KMail/1.9.9 References: <20081102181132.GA24737@thorin> <20081104191256.GB25519@thorin> <20081107192632.GF8625@thorin> In-Reply-To: <20081107192632.GF8625@thorin> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811221842.54928.okuji@enbug.org> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [RFC] Multi-terminal support (Re: [PATCH] terminal split) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2008 17:43:00 -0000 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. Regards, Okuji