Renewed Talk Of User-Space Consoles, Accelerators In The DRM Subsystem

Direct Rendering Manager (DRM) subsystem maintainer has shared some notes following this week's Linux Plumbers Conference in Dublin. In particular, the matter of whether the growing number of accelerators / AI devices belong within the DRM subsystem or elsewhere and separately there is renewed talks of user-space consoles to potentially push Linux distributions towards moving away from the in-kernel VT.

For over a decade there's been talk of replacing CONFIG_VT functionality with a user-space functionality. For some time KMSCON was also hacked on as a user-space console making use of Linux's kernel mode-setting (KMS) interfaces. But it's been a while since hearing ideas for killing the Linux kernel console (CONFIG_VT). But it turns out at LPC 2022 there was some renewed talks of going to a user-space console.

In particular, David Airlie commented on the brief discussions:

We'd like to move to CONFIG_VT=n as the console and vt subsystem have historically been a source of bugs but are also nasty places for locking etc. It also can be the cause of oops going missing when it takes out the panic path with locking bugs stopping other paths from completely processing the oops (like pstore or serial).
...
Once you think through all the paths and things you want supported, you realise the best user console is going to be one that supports emojis and non-Latin scripts. This probably means you want a lightweight wayland compositor running a fullscreen VTE based terminal. Working back from the consequences of this means you probably aren't going to want this in systemd, and it should be a separate development.

The other area discussed was around the requirements for a panic/emergency kernel console, likely called drmlog, this would just be something to output to the display whenever the kernel panics or during boot before the user console is loaded.

Airlie also noted the matter of cgroups for GPUs in a cross-vendor/driver friendly manner was also brought up in the "birds of a feather" sessions.

Airlie also published the notes from the accelerator BoF discussion. This revolves around the ongoing debate of whether AI/accelerator drivers belong within the kernel with some developers viewing them as their own subsystem while for now tossing them into char/misc while other developers argue that they belong within the DRM area given the commonality with GPUs.

From the LPC 2022 discussion, it seems the developers do agree making use of DRM subsystem functionality is generally beneficial. But both sides do see benefits of not tucking the accelerator drivers under drivers/gpu/drm. It likely will be moved into an area called drivers/accel for these forthcoming AI accelerator drivers while still employing DRM subsystem functionality. At the BoF ideas were also raised about better sharing over RAS (Reliability, Availability, Serviceability) code.

We'll see what pans out and how quickly these changes are realized with code.