Message-ID: <ec476a78-c721-420e-8c79-219d1c35a041@redhat.com>
Date: Tue, 27 Jan 2026 00:00:23 +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 15:36, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 02:05:36PM +0100, Jocelyn Falempe wrote:
>> On 26/01/2026 13:46, Greg Kroah-Hartman wrote:
>>> On Mon, Jan 26, 2026 at 01:26:34PM +0100, Jocelyn Falempe wrote:
>>>> On 26/01/2026 11:59, Greg Kroah-Hartman wrote:
>>>>> On Mon, Jan 26, 2026 at 11:48:50AM +0100, Jocelyn Falempe wrote:
>>>>>> 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.
>>>>>
>>>>> Great!  Then why is this even needed?  Who wants such a "let's not make
>>>>> up our mind until we boot" type of system?
>>>>>
>>>>> Given that traditionally the command line is a "secure" thing, that is
>>>>> locked down by distros and orginizations, who would ever be able to be
>>>>> changing this type of thing?  Who would want to support userspace that
>>>>> handles both at the same time?
>>>>>
>>>>> I don't see the issue here, if a distro doesn't want to support VT, then
>>>>> disable it in the kernel and all is good.  If they do want to support
>>>>> it, than enable it.  Don't do both :)
>>>>
>>>> Maybe the real issue is that VT cannot be built as a module.
>>>> That way the userspace would be able to load it only if it needs it.
>>>>
>>>> That's probably more complex than my 3 lines patch, but I can try.
>>>> Would you prefer it that way?
>>>
>>> If that would make it simpler for a distro to handle this, perhaps.  Try
>>> it and see, I think the last time this came up, unwinding this into a
>>> module just wasn't possible, but that might have been a long time ago, I
>>> can't recall.
>>>
>>> But again, why wouldn't a distro pick a "this is what we are going to
>>> support" line and stick with it?  Why would they want to support both?
>>>
>>
>> It's all about the transition. Talks about VT-less system started in 2012,
>> but since then no major desktop Linux distribution have done it.
> 
> Then perhaps it's not really ever going to happen if no one actually
> does the work and wants their distro to change to not have it.

To give some contexts, I proposed to switch to kmscon for Fedora 44, so 
once we are there, it will be feasible to switch off VT, in 1 or 2 
years. But the requirement to rebuild the kernel, makes it painful to 
test, and much harder to get accepted.

>> I think that one of the reason, is that if you switch off VT, of course some
>> users will complain, as it has a lot of implications.
> 
> Again, that's a distro's policy decision to make, don't force the kernel
> to support a wishy-washy distro's decision :)

Agreed, I can also keep this patch as downstream, if you think it's 
better that way. But I though it may interest other distributions as well.

> 
>> Telling them to go rebuild their kernel is not good.
> 
> Agreed, this is a policy decision a distro needs to make.
> 
>> Telling them to run
>> grubby to change the kernel command line until they find alternative for
>> their use case is better. They can experiment and do the switch when they
>> are ready.
>> Really it's nothing more than that.
> 
> Again, policy decision that a distro needs to make.
> 
>> I don't think a distribution will want to maintain VT and noVT for a long
>> time.
> 
> Please define "long time" given that no distro has even done this yet?

I hope it won't get longer than 1 or 2 year.

> 
> thanks,
> 
> greg k-h
> 

Powered by blists - more mailing lists