On Sat, Jun 02, 2001 at 09:44:13PM +0930, Brett Lymn wrote:

 > According to "Jaromír" Dolecek:
 > >
 > >I think this is quite useful feature and I'd certainly be happy
 > >if the option would be available.
 > 
 > I certainly think that having this option would be excellent too.
 > 
 > FWIW I am totally aghast that such a simple change can get such a
 > negative flogging.  Sure this OPTION will use more kernel memory but
 > so what?  If you have enough memory then you can ENABLE THE OPTION.
 > Arguments about the memory footprint being significant on an 8Meg
 > machine are specious - there are a lot of things you cannot do with an
 > 8Meg machine, run netscape, run emacs (well, maybe just), run a full
 > GENERIC kernel.  Such things Just Don't Work.  To use this as a

Yah, esp. considering that the flogging has yet to address any technical
aspect of the code (the feature is fine -- I'm concerned with the code
that implements it).

For those who are concerned about the memory footprint, what you seem
to have neglected to understand is that the total memory footprint is
the SMALL amount of code needed to implement this particular version
of the feature -- the scrollback area is mainained in the VGA character
cell storage area (of which a small part is visible when you're looking
at the text screen).

Now... the real concern I have is this isn't implemented as an MI
wscons feature -- it's vga-specifc.  This is wrong.

What really should happen is that the VT-switching and scrollback
features should be handled in a character cell abstraction in the
wscons layer -- and for display adapters, such as VGA, which have
character cell support in hardware, wscons should be able to use
that... but for display adapters which don't (i.e. most that work
as a linear framebuffer), some sort of shim to provde character
cell storage and display repainting should be employed.

Note that the "hpcmips" port has this as part of their display
support.  It really should be made MI.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>