Re: [PATCH] vt: Add enable module parameter

From: Greg Kroah-Hartman

Date: Mon Jan 26 2026 - 06:00:42 EST


On Mon, Jan 26, 2026 at 11:49:45AM +0100, Jocelyn Falempe wrote:
> 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.

But that's a distro's choice to make, why are you forcing this onto the
kernel? Either a distro wants to support a userspace with VT enabled,
or not. So then choose the kernel option you wish to have here and away
you go!

> And for distributions that already have kernel and kernel-rt, that
> means maintaining 4 kernels for all combination.

Again, that's a distro choice, you are now forcing us to maintain the
option due to the lack of an agreement in your organization :)

thanks,

greg k-h