From: Michael Gersten <michael@stb.info.com>
  To  : ggi-develop@eskimo.com
  Date: Thu, 19 Aug 99 00:10 PDT

Re: VC Switching

>>  We should do the vc-switching system *right* even if it means
>>  hacking it out entirely and putting it off for a while.
> 
>In my opinion, doing it *right* means not doing it in the kernel at
>all.  A kernel should just be managing the devices (such as video
>cards with whopping big memories), and allowing userspace to allocate,
>deallocate & use the resources, but not implementing user interface
>abstractions like VTs.
>
>Imagine if an X server emulated the text consoles (and there's no
>reason why it couldn't AFAIK).  It would be indistinguishable from the
>current system.  I'm not advocating that BTW :->, but I think it
>points the way to how it *should* be done.

So lets see if I understand this correctly.

You want to be replace a system that has the kernel moving a few K
around at a time with one where a multi-meg user process has to move
multi-meg graphic images around, because the kernel shouldn't
be doing UI?

Do you want the userspace to be responsible for drawing tabs? For
handling ctrl-U (ctrl-X for some) line erasing?

I've used both "pty" and "screen" on systems that did not support
virtual terminals. Screen was much too slow; pty did not support
redraws when switching. Kernel mode is more compatible (no program
ever crashes; pty crashed on large copy/pastes), faster (than screen),
flexable (programs/scripts can change the displayed terminal), and
alt-up arrow gets you a new window at any time.

The point is: The kernel's job is to give you abstractions. Whether
those are named file/directories (which don't exist on the disk
except as a kernel abstraction), IO channels for communications
(as opposed to just the ethernet packet buffer), device independance
(except for those communication channels, which have the equivalance
of device dependence), or "terminals" -- be it a physical screen,
multiple heads, or multiple virtual heads.

After Andy's comment on how badly designed the graphics cards
are -- commands may be partially given, the order of state register
settings is as important as the values of those registers --
I can fully see why the decision is that the abstraction of
the frame buffer -- a new device in the linux kernel -- is
to be something that alters the behavior of the terminal abstraction.

Michael