История изменений

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!).

Вполне себе разумно. more complex features like fully internationalized fonts and keymaps, which are *required* for emergency consoles with given keyboards — уже более, чем достаточно для нужности, гораздо лучше, чем прыгать вокруг тех же (юзерспейсных) фреймбуферных консолей, вооружившись uim-fep.

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!).

Вполне себе разумно. more complex features like fully internationalized fonts and keymaps, which are *required* for emergency consoles with given keyboards — уже более, чем достаточно для нужности, гораздо лучше, чем прыгать вокруг тех же фреймбуферных консолей, вооружившись uim-fep.