[systemd-devel] [RFC 00/12] Bugfixes for CONFIG_VT=n
David Herrmann
dh.herrmann at gmail.com
Wed Nov 27 10:48:35 PST 2013
Hi
So booting without VTs is still a horrible experience on desktop-linux. If
anyone tried, they were presumably running away in tears. This series is a new
attempt to fix that.
The first 4 patches are just small fixes/helpers. Patch 5 to 8 introduce sd-gfx
and patch 9-11 add tests/examples for sd-gfx. The final patch adds a first user
of sd-gfx to replace the kernel-internal terminal-emulator. The commit-msgs
should explain each change at length so I won't repeat it here.
To anyone interested in testing: If you apply this series, you can run
"./test-kbd" to test keyboard handling, "./test-gfx" to test graphics rendering
and "./systemd-consoled" to run the terminal-emulator. Note that you must run
all these from *within* an existing logind-session. That usually means from a
TEXT-VT. Also note that all these programs currently ignore the underlying VT
entirely (in case you run with CONFIG_VT=y). This has the side-effect, that all
keystrokes go to both, the VT and the application. This will obviously be
changed in later versions, but I wanted to avoid any VT calls in these helpers.
I currently work on logind to fix that.
I had to strip the font-patches due to ML size-constraints. The full series is
always available on the-often-rebased-console-branch at:
http://cgit.freedesktop.org/~dvdhrm/systemd/log/?h=console
Notes on where this is going, and *why*, below..
Happy Testing!
David
What is wrong with CONFIG_VT?
=============================
The VT layer in the kernel implements a rather complex keyboard layer (similar
to XKB, but less powerful), implements hard-coded device hotplug filters, input
handling, graphics-pipeline handling, font-rendering, terminal-emulation,
cursor handling and more. All this is used to render a basic text-UI *in the
kernel*!
However, moving UI handling into the kernel has a lot of disadvantages (the
same reason why user-space exists.. look it up). For completeness, some rather
obvious reasons are:
- non-swappable memory (even if you have no swap-partition, user-space apps
can avoid loading all fonts/keymaps into memory, which kernel-space cannot)
- security critical (any bug in the UI layer may allow *kernel-level*
privileges to attackers)
- stability (user-space apps can be easily restarted on failure; in
kernel-space, all kinds of memory may get overwritten..)
- code-duplication (we already have all this code in user-space, why copy it
into kernel-space?)
- simplicity (we wanna keep the kernel simple and slim, which prevents adding
more complex features like fully internationalized fonts and keymaps, which
are *required* for emergency consoles with given keyboards)
- configurability/controllability (ever tried assigning more/less CPU-time
to a given VT?)
- ...
So what reasons exist to have a UI layer in kernel-space? I only found 3
reasons, if someone knows more, let me know. I highly doubt there's more..
1) Early boot debugging
2) Panic/Oops screen
3) kdb kernel debugging
For 1) and 2) we have an experimental fblog/drmlog kernel module which just
prints the kernel log to all screens. This only requires ASCII glyphs and raw
access to DRM FBs. All the VT cruft can be dropped..
For 3): You're welcome to enable CONFIG_VT if you need a terminal-emulator for
kernel-debugging. My experience is that a serial-console is far more helpful and
reliable and avoids calling DRM modesetting in atomic-context (ugh? This fact
really makes me doubt anyone uses kdb.. Use kgdb!).
Long-term plan
==============
So the long-term plan for this series is to set CONFIG_VT=n. This actually
already works and you can boot your machine and start sessions like kmscon.
Even Xorg works if you apply a one-line patch. However, without VTs, legacy
sessions like Xorg will run in exclusive mode. To allow session switching, you
need systemd-logind. But even session-switching is already implemented. Though,
no real application uses that, yet (except for weston and some example code).
So most of the work is to fix all these applications to support VT-less mode.
This is already ongoing and will work soon (hopefully..).
So what does this series implement?
Well, if you run without VTs, you lack any kind of fallback console or fallback
login-screen. To guarantee that even without VTs there's a system-console and
login-screen, this series adds the most basic implementations of those to
systemd. This will *never* turn into a full-blown full-featured console. No
eye-candy, no useless features, NO BACKGROUND IMAGES!!!
The idea is to provide a fallback in systemd. If you want a fancy console with
more features, install kmscon and it will simply replace the systemd-fallback.
However, that means more memory-footprint, more CPU-requirements and a lot more
dependencies.
sd-gfx is a helper library in systemd to unify all the graphics, screen and font
handling. All following applications will use it, including:
(daemon-names are subject to change!)
- systemd-consoled: A systemd console (basic terminal emulator) used as
fallback session/console.
- systemd-splashd: A boot-splash for initrds. This will not include eye-candy
but is only required to accept password-input for
encrypted root-partitions. Use Plymouth if you want
eye-candy!
- systemd-welcomed: A login-screen to spawn sessions. This basically replaces
/sbin/agetty and /bin/login on a VT. After login it spawns
systemd-consoled.
- systemd-er: The emergency-room helper. Basically an even-more stripped down
systemd-consoled designed for developers. It avoids
session-management, seat-assignments, privilege-separation and
is just an hopefully-always-working-emergency-console. It's not
enabled by default. Think of it as a userspace-variant of
"magic sysrq".
This is stupid, why do you..
============================
..add so many dependencies and code to systemd?
You should consider that currently all that code is part of the *kernel*.
All this does is moving it out of the kernel. The first place that comes to
mind is systemd (and I couldn't imagine a better place, can you?).
Knowing that systemd already depends on the kernel, technically this doesn't
increase the codebase of systemd at all.
..kill my beloved kernel-console / linux-console?
I don't. Just set CONFIG_VT=y.
..duplicate kmscon?
Well, I wrote that and I consider it a successfull research project. Now
it's time to write something useful based on the lessons learned with
kmscon. No first attempt ever succeeds, right?
..miss the fact that a kernel-console is more reliable than user-space?
It's not. Why do you think that? You need a running shell to do anything
useful with a console. Where do you think this shell runs? (Hint: it's not
kernel-space.. and not outer space.. I wonder what "space" is left? Oh,
none, because your in-kernel fonts are non-swappable!)
..kill my panic/oops screen?
I don't. See above. I wrote fblog/drmlog for that.
..change a running system?
To make it better!
..add useful features like full-BMP-range Unicode-fonts, properly
internationalized keymaps, readable fonts on high-DPI displays,
access-separation, accessibility helpers and more to the system console?
Wait.. that's obvious, isn't it?
Besides, coding is fun!
David
David Herrmann (12):
event: allow EPOLLET as event flag
ring: add basic ring-buffer helper
bus: add two new bus_*_map_*_properties() helpers
build: add target to link binary sources
gfx: add sd-gfx library with unifont section
gfx: add keyboard layer
gfx: add graphics layer
gfx: add monitor
gfx: add kbd test
gfx: add graphics test
gfx: add unbuilt GL test
console: add systemd-consoled
.gitignore | 4 +
Makefile.am | 129 +
configure.ac | 38 +
make-unifont.py | 138 +
src/console/Makefile | 1 +
src/console/consoled-pty.c | 391 +
src/console/consoled-screen.c | 170 +
src/console/consoled-terminal.c | 371 +
src/console/consoled.c | 278 +
src/console/consoled.h | 128 +
src/libsystemd-bus/bus-util.c | 87 +-
src/libsystemd-bus/bus-util.h | 6 +
src/libsystemd-bus/sd-event.c | 4 +-
src/libsystemd-gfx/.gitignore | 1 +
src/libsystemd-gfx/Makefile | 1 +
src/libsystemd-gfx/gfx-drm.c | 2551 ++
src/libsystemd-gfx/gfx-kbd.c | 629 +
src/libsystemd-gfx/gfx-monitor.c | 1767 ++
src/libsystemd-gfx/gfx-unifont.c | 273 +
src/libsystemd-gfx/test-gfx.c | 302 +
src/libsystemd-gfx/test-gl.c | 342 +
src/libsystemd-gfx/test-kbd.c | 314 +
src/libsystemd-gfx/unifont.bin | Bin 0 -> 2162688 bytes
src/libsystemd-gfx/unifont.hex | 63488 +++++++++++++++++++++++++++++++++++++
src/shared/ring.c | 213 +
src/shared/ring.h | 54 +
src/systemd/sd-gfx.h | 405 +
27 files changed, 72058 insertions(+), 27 deletions(-)
create mode 100755 make-unifont.py
create mode 120000 src/console/Makefile
create mode 100644 src/console/consoled-pty.c
create mode 100644 src/console/consoled-screen.c
create mode 100644 src/console/consoled-terminal.c
create mode 100644 src/console/consoled.c
create mode 100644 src/console/consoled.h
create mode 100644 src/libsystemd-gfx/.gitignore
create mode 120000 src/libsystemd-gfx/Makefile
create mode 100644 src/libsystemd-gfx/gfx-drm.c
create mode 100644 src/libsystemd-gfx/gfx-kbd.c
create mode 100644 src/libsystemd-gfx/gfx-monitor.c
create mode 100644 src/libsystemd-gfx/gfx-unifont.c
create mode 100644 src/libsystemd-gfx/test-gfx.c
create mode 100644 src/libsystemd-gfx/test-gl.c
create mode 100644 src/libsystemd-gfx/test-kbd.c
create mode 100644 src/libsystemd-gfx/unifont.bin
create mode 100644 src/libsystemd-gfx/unifont.hex
create mode 100644 src/shared/ring.c
create mode 100644 src/shared/ring.h
create mode 100644 src/systemd/sd-gfx.h
--
1.8.4.2
More information about the systemd-devel
mailing list