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

[Eric S. R. <es...@th...>]

Jim Peters <ji...@ag...>:
> 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 ?

One big one.  I fear some terminal emulation has to be in the kernel,
otherwise the user will lose badly in pathological situations where the
hypothetical daemon doesn't start up.  Never forget the run-level 1 case.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

"As to the species of exercise, I advise the gun. While this gives
[only] moderate exercise to the body, it gives boldness, enterprise,
and independence to the mind.  Games played with the ball and others
of that nature, are too violent for the body and stamp no character on
the mind. Let your gun, therefore, be the constant companion to your
walks."
        -- Thomas Jefferson, writing to his teenaged nephew.