[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2026012613-cotton-jellied-b67a@gregkh>
Date: Mon, 26 Jan 2026 10:33:08 +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: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?
> 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 :(
thanks,
greg k-h
Powered by blists - more mailing lists