Re: [PATCH] vt: Add enable module parameter
From: Jocelyn Falempe
Date: Mon Jan 26 2026 - 05:55:53 EST
On 26/01/2026 11:20, Greg Kroah-Hartman wrote:
On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
This allows to build the kernel with CONFIG_VT enabled, and choose
on the kernel command line to enable it or not.
This says what is happening, but not why?
Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
Why are we using a 1990's technology for a new feature? What is this
going to allow to have happen? Who needs/wants this? Who will use it?
For what?
The goal is to ease the transition to disable CONFIG_VT.
So if this is merged, you can boot without VT on any Linux distribution,
without rebuilding the kernel.
But that's a distro-specific thing, the distro should be enabling or
disabling the option as it needs, it should not be a user-configurable
boot-time selection option as userspace depends entirely on this either
being there or not. Why would you have a kernel with both options but
userspace without that?
Actually the userspace side works with or without VT, at least with Fedora, I've my Gnome session in both cases.
This option will also allow a distribution to disable VT by default, but
users that really wants this can enable it on the kernel command line,
without rebuilding the kernel.
Why would a user want that? If a user really wants it enabled, why
would userspace even still work and why would they want to not rebuild
the kernel?
Rebuilding kernel is not user-friendly, changing a kernel cmdline parameter is much easier.
It will also avoid hacky solution in userspace like this:
https://overhead.neocities.org/blog/systemd-logind-seat/#very-hacky-solutions
Surely that can't be the only way, why can't userspace just handle this
"properly" if it wants to?
There is no way for userspace to disable the tty that are running in the kernel. It can at best ignore them, but for me it's not a proper solution.
Signed-off-by: Jocelyn Falempe <jfalempe@xxxxxxxxxx>
---
drivers/tty/Kconfig | 13 +++++++++++++
drivers/tty/vt/vt.c | 5 +++++
2 files changed, 18 insertions(+)
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index 149f3d53b7608..2b94c2710687a 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -41,6 +41,19 @@ config VT
If unsure, say Y, or else you won't be able to do much with your new
shiny Linux system :-)
+config VT_ENABLE
+ depends on VT
+ default y
+ bool "enable VT terminal" if EXPERT
So no one will ever really use this config option?
And you are doing 2 things in this patch, not just one, unlike what the
changelog said :(
I can split that in two if you prefer.
I'm objecting to the patch doing something other than what the changelog
describes, which as you know is not a good thing.
ok, I can fix that in a v2.
Adding a module parameter, and adding a Kconfig option, to choose the
default for this module parameter.
I really don't like adding new module parameters that we are going to
have to now support for forever. Why not just rely on the config option
being there or not as-is? That's why we allowed it to be turned off at
all, because userspace was going to be moved to not need it anymore.
Why would we want to support "both" at the same time in the kernel?
This parameter is there to ease the transition to VT-less system. So by maintaining this few lines of code, it will be possible to deprecate the whole VT in the future.
If a module parameter is not a good solution, I'm open to any solution that can disable vt from the kernel command line (userspace init runs to late to disable vt).
thanks,
greg k-h