DRM Kernel Log Renderer Proposed For Linux

One of the long-standing proclaimed benefits of Direct Rendering Manager (DRM) graphics drivers for the Linux kernel was that it would be possible to have "Blue Screen of Death"-like error messages in cases of kernel issues. That feature is now closer to being realized while also advancing another goal of disabling VT support within the Linux kernel.

David Herrmann, the open-source developer that's long been working on killing off CONFIG_VT (VT support within the Linux kernel), called for developer comments today on his DRM kernel-log renderer. Herrmann explained this work as:

On modern linux user-space, the VT subsystem is no longer needed for system consoles. Although most DEs will fail if VTs are disabled, there are several gfx-systems that support this mode. Especially the lower system stack has been extended to work without VTs.

However, there is one major drawback if VTs are disabled: You don't get oops/panic-screens nor early boot-debugging. The VT subsystem registers a console-driver, thus displays the kernel log and oops/panic screens in those situations. This patch introduces a fallback for CONFIG_VT=n.

A new DRM-Log core is added. At its heart, DRM-Log maintains a log-buffer of kernel-log messages. It registers a console-driver and pushes new messages into this buffer whenever they appear. The size of the log-buffer can be changed via drm_log_ensure_size(). Initially, a suitable buffer is chosen, but whenever drivers register high-res CRTCs, they ought to increase that buffer to guarantee there's always enough data to render the whole screen. This log-buffer is managed at the character-level, not pixel-level. It is shared across all users, supports parallel, atomic readers and writers and supports seamless resizing.

David ended his RFC message with, "With this (and the high-level integration) in place, you can easily disable CONFIG_FB, CONFIG_VT and CONFIG_FRAMEBUFFER_CONSOLE. Combined with a proper user-space system-console, you will end up with more features, less bugs and definitely some happy kernel maintainers." We'll keep watching this DRI thread to see how kernel developers accept this new DRM kernel-log renderer for pumping out kernel debug information in case of Linux system problems.