linux-kernel - Re: [PATCH] vt: Add enable module parameter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2026012659-credit-suing-72ce@gregkh>
Date: Mon, 26 Jan 2026 11:30:44 +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 11:20:21AM +0100, 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?

And to follow-up on this, if a distro wanted to support this, why not
just provide 2 different kernel images?  One with this enabled and one
without?  It's up to the distro to support such a thing, not the kernel
community, right?

thanks,

greg k-h