On Tue, 23.07.13 08:57, Al Viro (v...@zeniv.linux.org.uk) wrote: > > 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.
The UML tty devices are in most regards pretty much like serial TTYs where there's also no meta-information available which terminal emulation is actually spoken on it, and that's covered pretty much OK everyhwere... > 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. Which major/minor you use is irrelevant to userspace. The userspace API however assumes that /dev/tty[1..63] refers to the tty devices of the virtual console. As long as you provide some other TTY under that name then the virtual console TTYs you simply provide a broken API to userspace, and hence programs break. systemd does, gpm does, X11 does, and everything else that interfaces with the VC via VC APIs does too. Just pick a different name for the TTYs that UML uses, just not /dev/tty[1..63] and everything is fine. That's what the virtualization folks did with their hypervisor consoles, and is what we required from the container folks too. Lennart -- Lennart Poettering - Red Hat, Inc. -- 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/