public inbox for linux-serial@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jocelyn Falempe <jfalempe@redhat.com>
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:46:13 +0100	[thread overview]
Message-ID: <2026012653-designer-capably-d575@gregkh> (raw)
In-Reply-To: <99371939-e9b2-4114-8e27-e605ebf941de@redhat.com>

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?

thanks,

greg k-h

  reply	other threads:[~2026-01-26 12:46 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
2026-01-26 12:46             ` Greg Kroah-Hartman [this message]
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=2026012653-designer-capably-d575@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=calixte.pernot@grenoble-inp.org \
    --cc=jfalempe@redhat.com \
    --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