From: Jocelyn Falempe <jfalempe@redhat.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jirislaby@kernel.org>,
Nicolas Pitre <npitre@baylibre.com>,
Calixte Pernot <calixte.pernot@grenoble-inp.org>,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: [PATCH] vt: Add enable module parameter
Date: Mon, 26 Jan 2026 13:26:34 +0100 [thread overview]
Message-ID: <99371939-e9b2-4114-8e27-e605ebf941de@redhat.com> (raw)
In-Reply-To: <2026012642-threefold-atypical-a3ad@gregkh>
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?
>
> thanks,
>
> greg k-h
>
next prev parent reply other threads:[~2026-01-26 12:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-26 9:21 [PATCH] vt: Add enable module parameter Jocelyn Falempe
2026-01-26 9:33 ` Greg Kroah-Hartman
2026-01-26 9:43 ` Jocelyn Falempe
2026-01-26 10:20 ` Greg Kroah-Hartman
2026-01-26 10:30 ` Greg Kroah-Hartman
2026-01-26 10:49 ` Jocelyn Falempe
2026-01-26 10:57 ` Greg Kroah-Hartman
2026-01-26 10:48 ` Jocelyn Falempe
2026-01-26 10:59 ` Greg Kroah-Hartman
2026-01-26 12:26 ` Jocelyn Falempe [this message]
2026-01-26 12:46 ` Greg Kroah-Hartman
2026-01-26 13:05 ` Jocelyn Falempe
2026-01-26 14:36 ` Greg Kroah-Hartman
2026-01-26 17:24 ` Nicolas Pitre
2026-01-26 22:59 ` Jocelyn Falempe
2026-01-26 23:00 ` Jocelyn Falempe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=99371939-e9b2-4114-8e27-e605ebf941de@redhat.com \
--to=jfalempe@redhat.com \
--cc=calixte.pernot@grenoble-inp.org \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=npitre@baylibre.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox