[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?


More information about the systemd-devel mailing list