Message-ID: <2026012648-vantage-mummified-2a43@gregkh>
Date: Mon, 26 Jan 2026 11:20:21 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Jocelyn Falempe <jfalempe@...hat.com>
Cc: Jiri Slaby <jirislaby@...nel.org>, Nicolas Pitre <npitre@...libre.com>,
	Calixte Pernot <calixte.pernot@...noble-inp.org>,
	linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org
Subject: Re: [PATCH] vt: Add enable module parameter

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?

> 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?

> 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?

> > > Signed-off-by: Jocelyn Falempe <jfalempe@...hat.com>
> > > ---
> > >   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.

> 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?

thanks,

greg k-h

Powered by blists - more mailing lists