bug-grub
[Top][All Lists]
Advanced

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

Re: Serial Line boot may not properly clear the screen


From: Yoshinori K. Okuji
Subject: Re: Serial Line boot may not properly clear the screen
Date: Tue, 22 Jan 2002 06:23:34 +0900
User-agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryoae) APEL/10.3 Emacs/20.7 (i686-pc-linux-gnu) MULE/4.0 (HANANOEN)

[I added bug-grub to Cc:.]

At Mon, 21 Jan 2002 16:54:34 +0100 (MET),
Klaus Reichl wrote:
> Do you think it is possible than to code like:
> 
>    if (term->gotoxy /* or term->getxy */)
>       algorithm for terminals with positioning
>    else
>       algorithm for DUMB like terminals
> 
> instead of term (terminal & TERMINAL_DUMB)?

I'm not sure. In my feeling, using a function pointer to test a
feature is ugly. This is not ugly only when you want to test the
very feature provided by the function itself. For example, it is the
Right Thing to test the member "embed_func" of the structure
"fsys_entry" when GRUB wants to embed data into a filesystem.

However, if you want to check if a terminal driver can handle a fancy
interface, it is the Wrong Thing to test the member "gotoxy",
IMO. That's because the function says just that it can move the cursor
arbitrarily, and there is no reason why getxy shouldn't be used for
the same purpose.

So I think it would better for each terminal driver to have a feature
table (bit fields).

> Me too, however, maybe this behaviour should be on another switch to
> terminal.
> 
> e.g. terminal --dumb          => no ANSI positioning
>      terminal --no-line-edit  => not even line editing

That's really flexible, but I'm afraid that we are making the code too
complicated. At the moment, I don't know who uses GRUB with dumb
terminals, besides you and Christoph. So it isn't so important to
support various types of dumb terminals, I think.

If anyone uses GRUB with a different type of a dumb terminal, he/she
should notify us of the fact ASAP...

Thanks,
Okuji



reply via email to

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