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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
