[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <40fa8cab-af36-4420-9099-511474833fe1@redhat.com>
Date: Mon, 26 Jan 2026 11:49:45 +0100
From: Jocelyn Falempe <jfalempe@...hat.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
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 26/01/2026 11:30, Greg Kroah-Hartman wrote:
> 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?
That's clearly not an option, they will prefer to keep VT enabled
forever than adding yet another kernel package. And for distributions
that already have kernel and kernel-rt, that means maintaining 4 kernels
for all combination.
>
> thanks,
>
> greg k-h
>
Powered by blists - more mailing lists