From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 043C82D9EC5 for ; Mon, 26 Jan 2026 23:00:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769468436; cv=none; b=NtcRj8Y7Re8NTgJJJGFHIpkGmS01E5X+SuweJljQdL7f5GNJ/mPltQ44Vi6nx7P1248fIizfS04X95duGf37gk4y9Inn7gMQpQau93GQ6DVkABDGksAstAwbm1qVJDD7fCcEFsLkjj0rUAS0CTcqmFMbjWeeICqH8d2JjvrMSPM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769468436; c=relaxed/simple; bh=QdYsYZ/XZ/BhrWZiC3LmVOgd0ZnKqPTEavFlSQj7vKA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=dXB91Knd+8+w0HutoxIcJ4rA+eWtjJ9vHtJIeCik2xPumpd2m/cPLVsIb/HD1F40tpPyaE/uy6s/DliLZuNUJGVPcn6kPJv0yO6UbnlgJ6TZSaaNo7iFm1MEOjX3PUlDd/ROWZbZijfkt1daW01c2wZdQS/a7ZGX0TVBYgJBI+w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=dlab1qVf; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=XefqGNXB; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="dlab1qVf"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="XefqGNXB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1769468434; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yy9iHITJImOaWp+w2IDttpcClHHB6iVERPgCL4cF2OU=; b=dlab1qVfKYjCb3Wmiq0ln5ikuPYMCUsGFyQ7YjOebxVdaZXpcfNUdkKLO/NEuvgiadp8zO olMoXztCmamZRRJXsfDV4LRnhLbSzEiaRv3D3RaxQMy5aBAAjBU9jKaBhOBP/01gei2vLm 7yzZBaDNkQAAC9CIQ54cdy1WglwyIdE= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-308-QwN5dOAuPsq25dcsx11iPA-1; Mon, 26 Jan 2026 18:00:29 -0500 X-MC-Unique: QwN5dOAuPsq25dcsx11iPA-1 X-Mimecast-MFC-AGG-ID: QwN5dOAuPsq25dcsx11iPA_1769468428 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-47ee33324e8so38182535e9.1 for ; Mon, 26 Jan 2026 15:00:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1769468428; x=1770073228; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=yy9iHITJImOaWp+w2IDttpcClHHB6iVERPgCL4cF2OU=; b=XefqGNXBR0VT1hdmvDkZAMRXmzbaQS/xcvxsb+lv75IJhlIzM6Vdww3aAY77/J+ExP UjR9yIaO40FGFb/JlTHDbwoHHkgADyaxheJuio18NAjyyceyguTaGjlVp/GfZhAsolOK oxaU3SeBjY5wdKaYh459xzITTGOTmYj+cgcRS69yRZSKA+/Z3TAKqFFoSt40a8kTb1Tw Ck8uXQS7qkL56EbYbO9qe+Pi7B5XDJGkA+RMbci5KbGL53pl6im+TiKyrUGevYDbT7st pC5WVO9wVmyawhP7szt+AD9wIjhNavF5B1cMQTc2aVlXsUwytN+6duxbdZn3MZd+lpe1 ywIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769468428; x=1770073228; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yy9iHITJImOaWp+w2IDttpcClHHB6iVERPgCL4cF2OU=; b=kj8xh9cWne8i+nuYXwauMbKhGsesEHc4/KeG6eGPdiDak2CZ9X72wM05yKi5vxXhJi aDVxf6I4ri+Q6lOds42/bBG6Y+6Y+1FFnvOt/sO64NOkthbMRnWXPayV0in/JewkfQvA Aso/KqJ/h1cRwjyr/I933FXwPD3BCT+LH4d5WYHxKiPXmoUJTKjiBeZtzyKEazmzpw2T V3fj3Zf0m/bAa6+Ry1KyFI/1pc8am0BlSeMXL7wTPEUyEj7sCCT+f9pMy7fBKN//1Ah9 IHp8b6GoAGlI9sHtrRJt3VpU0an8BuVmFR6Revs7ti6hoafIWIVih48jKUptisnjm5lj GHCQ== X-Forwarded-Encrypted: i=1; AJvYcCUNI4i5+zYJedWrONUIpPJJHgUqwnQnFgaXEwQpCAdQQ/Ykxm2COV/h3cmXZnFEgVjJMOB0VUvspEDTBh0=@vger.kernel.org X-Gm-Message-State: AOJu0YzwnRPioL1kCk7GS30LC5hsd4Inuto5InDMC9jdoPwbCmbPRqV1 iaotnWh67tdn1oxDCNnoeKGVs1CanMmIPgGoignElIMs2G0SqWAcoBgdEDyEJT//GrPyiSWZGpl b9VAVRqTnuoykBLAIg2Gb3nupK02FE0cBZsARmyPbaYPeHl51pcDrXGqIVHEHEZePrA== X-Gm-Gg: AZuq6aJfTygU5zlmrqwpmNxQyELYWvYhQqVuZitleaJRXcdtDTTDgIz3CmcSRxYMahN 4wQEVSEmnRLlqaZIq8qGxxC5on+VZmbBg9tTurmvp/uudbjWVYwauNsVoMRVvScFLtSv0n9YDIX AFTKSQHQRQYONS0GGCOnwqfN9dLXZF7oQiR7DPo1vSea3VZG8Ha0fcOBwGQleJh2ySNRhrLExcD 4YRmx26WGIsmhsUS7sOv1ZCowqzBk6u7otaqfqB4VfV14vtjNsElGAcbvtz+71GhEVbXVLYO2Nb hM+SINmfm9ZIr/1ESAvisSBoeE2lHGIRCJprA+BizaUqwy2/uVOdzcEvV6dpG3RnXIen9t3EwOS KmDdMbVSMHbGogkbdnQGy4CRPiy74XBVJTO703MyIXe26MBnOmQ== X-Received: by 2002:a05:600c:314f:b0:480:3b4e:41ba with SMTP id 5b1f17b1804b1-4805cf669b2mr80349915e9.18.1769468427919; Mon, 26 Jan 2026 15:00:27 -0800 (PST) X-Received: by 2002:a05:600c:314f:b0:480:3b4e:41ba with SMTP id 5b1f17b1804b1-4805cf669b2mr80349755e9.18.1769468427499; Mon, 26 Jan 2026 15:00:27 -0800 (PST) Received: from ?IPV6:2a01:e0a:c:37e0:8998:e0cf:68cc:1b62? ([2a01:e0a:c:37e0:8998:e0cf:68cc:1b62]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066c0f3f7sm26880285e9.13.2026.01.26.15.00.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 15:00:26 -0800 (PST) Message-ID: Date: Tue, 27 Jan 2026 00:00:23 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] vt: Add enable module parameter To: Greg Kroah-Hartman Cc: Jiri Slaby , Nicolas Pitre , Calixte Pernot , linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org References: <20260126092234.713465-1-jfalempe@redhat.com> <2026012613-cotton-jellied-b67a@gregkh> <48be84fb-bee4-4a22-bde4-0d0c78282f80@redhat.com> <2026012648-vantage-mummified-2a43@gregkh> <45526d98-57b6-456e-babc-61b7331318c0@redhat.com> <2026012642-threefold-atypical-a3ad@gregkh> <99371939-e9b2-4114-8e27-e605ebf941de@redhat.com> <2026012653-designer-capably-d575@gregkh> <286bfe2e-796e-4c71-a75c-4967450edaab@redhat.com> <2026012620-retool-gloater-6cd3@gregkh> Content-Language: en-US, fr From: Jocelyn Falempe In-Reply-To: <2026012620-retool-gloater-6cd3@gregkh> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 >