Lennart Poettering wrote: > They can call their ttys any way they want. If the call them > /dev/tty[1..64] however, then they need to implement the VC > interfaces. All of them. > > Also note that some hypervisors implement /dev/hvc0, /dev/xvc0, > /dev/hvsi0 and suchlike. Theser are also ttys, which are used for > interfacing in a VT-like way the virtual machines. But they do not claim > to ve the real VT, they hence picked different tty names.
Got it. So, it should have provided /dev/tum* (or something) instead of /dev/tty*. But what can we do about it now? I certainly cannot remove /dev/tty* and murder the users. Let's say I pull a few all-nighters and actually finish that darned VT emulation. [2/2] is unnecessary now, because vconsole-setup.service passes. But we still need my original [1/2], since UML connects /dev/console to fd:0,fd:1 by default: otherwise, new users will be confused that they don't get a prompt when they execute: $ ./linux ubd0=arch-rootfs Once this gives a prompt, why bother connecting to /dev/tty* at all? If I want more prompts, I just start a tmux session on /dev/console. Done. As far as I'm concerned, the /dev/tty* devices in UML are historical crufts, and the net utility of my all-nighters is some minor "prettification": vconsole-setup.service passes. Big deal; users can live with vconsole-setup.service failing. Again, I'm not at all arguing about what is Right or Wrong, or what is Broken or Non-Broken. It's fine to emphasize how broken UML's behavior is; all I care for is a solution that doesn't involve users suffering. Do you have something in mind? Cheers. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel