[systemd-devel] [PATCH 2/2] vconsole-setup: setup negative conditional on uml
lennart at poettering.net
Sun Jul 21 17:07:40 PDT 2013
On Sat, 20.07.13 15:55, Ramkumar Ramachandra (artagnon at gmail.com) wrote:
> Kay Sievers wrote:
> > I would rather see vconsole to detect the mess and silently give up,
> > instead of adding exotic options for really weird faked and wrong tty0
> > setups.
> um Linux lacks VT102 emulation, and this is a documented fact.
> Therefore, your code:
> unsigned char data;
> data = TIOCL_GETFGCONSOLE;
> return ioctl(fd, TIOCLINUX, data) >= 0;
> is guaranteed to fail. Not because something went "wrong", or due to
> some "mess" or "fakeness", but because it was perfectly expected. I
> discussed this on LKML, and posted an explanation about this already
> That said, I don't know what to do about
> systemd-vconsole-setup.service: I just followed Zbyszek's suggestion.
> Penalizing um Linux for not doing VT102 emulation, and always failing
> a service seems user-unfriendly to me.
So, we should not add hacks to work around UML brokeness to systemd. I
am all happy with supporting kernels with and without VC subsystem, but
the thing UML is doing is just wrong.
The VT subsystem makes a few guarantees. You get /dev/tty[1..64], you
get /dev/tty0 as special multiplexer, and you get /dev/vcs[1..64] and
/dev/vcsa[1..64] to access the terminal buffer. On the /dev/tty[1..64]
devices you can speak TERM=linux and issue the ioctls listed in
console_ioctl(4) all work. You get some files in /sys like
/sys/class/tty/tty0/active and they will generate the right events via
POLLIN in poll(). That all together is the VT API.
The VT API like this is used by numerous applications. systemd itself,
logind, X11, gpm, mc, openvt, ...
UML provides /dev/tty1, but it implements the wrong TERM on it, supports
none of the ioctls, doesn't provide the other matching devices, or the
sysfs interface. That is just wrong. It's totally fine if it provided
its TTY under some other name, but doing so under the name of /dev/tty1
is just wrong, because that is the interface to the VT, and UML doesn't
have anything resembling that. It just has some normal tty of some kind,
but certainly *not* a VT!
I am happy with rearranging things here and there for projects like
UML. However, I am not happy with doing that for an interface that is
simply broken and incorrectly implemented by UML: they should not claim
the VT devices if they don't implement it. That's just broken. Our
approach is that software needs to be fixed where it is broken, not
worked around in other software,
So please, ask the UML guys to somehow cleanup their VT mess. It's their
broken code, and their job to fix it.
We had the same discussion regarding how LXC and suchlike set up VTs in
containers. It's the same story there: people assumed that mounting
some ptys to /dev/tty[1-64] was a good idea, but it really isn't. We
were pretty clear in that case, and we are going to be clear in the UML
case: you are doing it wrong. Either support VTs or don't, but don't
claim you do, but actually support something very wrong and
different. And as you long as your VT support is so broken we will not
support it in systemd.
I can understand if you are disappointed by this, but please try to see
it from out side: we want clean, supportable code, and we want code that
works correctly. Because, even if we added a work-around to systemd: the
next thing would break soon if you try to run it on UML. Better fix UML
than add work-around to all those projects individually.
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel