Re: [PATCH] um: change defconfig to stop spawning xterm

[Al Viro <viro@ZenIV.linux.org.uk>]

On Tue, Jul 23, 2013 at 07:47:07AM +0200, richard -rw- weinberger wrote:
> Adding Al again, someone dropped him from the CC list...

FWIW, all this crap stems from the old decision to use major 4 for
uml consoles.  And it was a bad decision, no arguments here.
It's also a decision we are years too late to revert.

a) VT102, let alone the extensions to it, is simply wrong for uml;
if it's understood by anything, it's on the host userland side.
xterm(1) has a notion of two-dimensional array of characters on screen,
organized in logical lines, etc.  So does screen(1).  So does
drivers/tty/vt/* (i.e. the kernel side of virtual console).  uml
console does *not* have such a notion - it passes a linear stream
of octets, sight unseen, to whatever's on the other side of connection.
Doing an equivalent of drivers/tty/vt/* would mean maintaining such
a 2D array internally *AND* somehow passing updates to that beast
to whatever's on the other side.  That could be done (after all,
libcurses manages), but it won't be compatible with existing setups
and it should be a separate driver, anyway.  Granted, it would've
made a whole lot more sense in role of /dev/tty<n>, but it's too late
for that now.

b) changing the major of /dev/tty<n> on uml will break existing setups.
Ain't feasible.  We probably can get away with making that controlled
by kernel option, and it might make sense to try going that way, but
I'm not entirely convinced it's worth bothering.  Up to uml maintainer...
IMO if we go that way, we ought to pass the relevant part of config
(i.e. is it xterm or pts or plain opened file) in the event udev
gets, so that the userland would have at least a chance of dealing
with another real problem - selecting TERM value for getty.