Re: [Linuxconsole-dev] Splitting console driver and VT emulation

[Vojtech P. <vo...@su...>]

On Wed, Mar 08, 2000 at 12:30:08PM +0000, Jim Peters wrote:
> > > Make the terminal emulation a loadable module.  Have the console driver
> > > look for module "vte" and then you can use the alias mechanismen of
> > > modload to push the appropriate module.  If that fails fall back to dumb
> > > line mode (similiar to the framebuffer initialization).
> > > 
> > > Does that appear a workable solution?
> > 
> > Yes:)
> 
> Another idea - the terminal emulator can live in user-space (a terminal-
> emulator daemon ?), sitting on top of the normal Linux console code, or
> fbdev, or GGI, or X, or whatever.  It can use /dev/ttyp? as the tty device.
> 
> It doesn't need to go into the kernel.  If we take the GGI approach of only
> having hardware-banging stuff in the kernel, then there is no reason to have
> the terminal emulator live there as well.  If we can get all the services we
> need from the kernel one way or another, then the terminal emulator can live
> outside.  This is what xterm does anyway - sits on X, grabs a pseudo-tty.
> 
> This may need to be a high-priority process to keep the display up-to-date
> in the face of high system loads.  This is a downside, but there is also the
> up-side that the application does not block whilst the display is updated
> (as with a kernel solution), but only when the pipe buffer is full.  A
> daemon updating once every frame or so could cut out a lot of unnecessary
> updates when applications have rolling counters or whatever.
> 
> Any objections to this idea ?

Emergency situations. Cases when the daemon is not started. Cases of
system crashing and kernel oopsing and writing data to the screen. While
a full vt100 isn't needed for these cases, *some* terminal is needed,
right in the kernel.

-- 
Vojtech Pavlik
SuSE Labs