[systemd-devel] [PATCH 2/2] vconsole-setup: setup negative conditional on uml
Ramkumar Ramachandra
artagnon at gmail.com
Mon Jul 22 01:01:25 PDT 2013
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.
More information about the systemd-devel
mailing list