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.129.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 25EEA3358D0 for ; Mon, 26 Jan 2026 12:26:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769430403; cv=none; b=lmvStVSZDscHxcXce3r7oGVY4eo/uGiocP4L/KWXO8bWtw5pB5Ddu20PEdPntkQzL/KMb7ewmC3z7I5qZjglemwPwj6kPdi5ZUrBg08sjWjOysyoPJporGeTqIUPza6s9dmBYpt/gmRBgdVT60CfEBerE7+QJARGivl6Rgzu7Yw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769430403; c=relaxed/simple; bh=UQBNreu95MI4Q8V9RC58x2ayLPxj24KYhxgW8Vs2nGE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=iigms8cTJ5g+sK4PAgHNY1am7Z7P1brQiNL3JCO0t5PSZEXlTuDORTzV9D0ajHY0mdjTlwUKIKJURA8ti5FgpWVqyjNBQyZBSxGjCORgUyLbsghxkP2+zqeGmmHSzBbOyP+en9c0rI3k4iORBDIh/3p3Ximv5AwvewLOxsPRZsM= 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=DcK30XwT; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=iiYF8DDH; arc=none smtp.client-ip=170.10.129.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="DcK30XwT"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="iiYF8DDH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1769430401; 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=o8Faa0L+qn+PMM8GCfMwSNgO72PmHHclarZT7GZadoQ=; b=DcK30XwTjpTeUYkGN3WFQOpD3a1qwtd/Gh5b7KEQNaiQPRZJY8A9whRxdV5cUfhfTb6DGU F8Rwnftgrfxc4wdTmFaeayyzjFdRQGRgaketXlSRQu5o91VmdxQaeEivYEiCktdjhe1XER Tz3lHh204slIHl9ZDGeG9AUT0z1ZzA4= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-115-6FsjlPCyOmqYiPJqqLipwg-1; Mon, 26 Jan 2026 07:26:39 -0500 X-MC-Unique: 6FsjlPCyOmqYiPJqqLipwg-1 X-Mimecast-MFC-AGG-ID: 6FsjlPCyOmqYiPJqqLipwg_1769430399 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4779ecc3cc8so38632945e9.3 for ; Mon, 26 Jan 2026 04:26:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1769430399; x=1770035199; 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=o8Faa0L+qn+PMM8GCfMwSNgO72PmHHclarZT7GZadoQ=; b=iiYF8DDHc5xGMVtsb5JG/RprlSZvlVTndulTTnhigF7dLw2Fhn1C8DBxrPSu+YwWtl bH4vVTelWw58IkIPFgX8QB+GgF51GV0A65HndPcIKxabLCTrN12yAr7tNgp0MGwNirAb CQP5/xmfJ00/wuuoEXeqGKMziZskqGDdvkiUB2gKqAW6Ayt5PBACgv9/lePoPlfVE5Ty mPmyLGY1lJdKHiZDGlOP+VLXBkozG+OmmjSw0SAP7PAhhM+fQBor+N/vPL+ufAkuyaJO h6i94E7uSM/6oxgL4SsyGrRci/Nf8/6A9Wdea3LtY1dRVBJhI+6tbCy69zZw7YSLi/Iz +Bag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769430399; x=1770035199; 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=o8Faa0L+qn+PMM8GCfMwSNgO72PmHHclarZT7GZadoQ=; b=XPL+n1T9WeMQGuriWNAos1kj+icw83Nh+JCNrNtHzi70Z/PgFz1xPRDuFJXCnf+5fs 1/3iFK1vFfQ3hwFH/R3ojBzuzF/wb7glKEadiKYlJeEoQ2u5p7ZddYYOlXFgfsAVRvrt fa07qTyaMrjwQWtBNubs6r5hiww9grt5ijWsbePdaU9u64Es9ty7sZGTQ6D4HhdqgbZY twog5YMTtke4KYl++6VW9OBJkrT8U9t5JF6IUTvGUFYREU17gk/qhXYNTJYWZEHo/0fu KnDEtdXS2UY/kh7QjFbn+ZoeAbAQVS2Wy9QxQI5Z82XWyWE8wPt3zblWOp2vVO2iM90V yUTQ== X-Forwarded-Encrypted: i=1; AJvYcCX3ASgljrf5t76UFm8sDULbU6mTJwBEOA5jBlL9F+r1UVV0XeM3Wk97yDtlZiFCzSREBSYmA780lXinbQY=@vger.kernel.org X-Gm-Message-State: AOJu0YzG21y9aVzqTqiz702hifcIYov1rDibMMEXjAu4lJ6tWeEK56yO hx6sZJE6jz+Uc/Q5bFcTs+bkKQ2rw7LzboeIHV1YG+GO0vqyF/Iu3D6rcCVopjS68af/gpbWKTA pfBDvuAm6RkUFWaFMayux1Njaqab5fW7J0L3Wl2yAP4+qBdJx9nWpUNbmT3Sm8pJPAQ== X-Gm-Gg: AZuq6aJ/sIaOffXStKRftRHS1dgIuQ1lvO0sTAya77zlTyvmQX7fVHI2MurFWR5rDk5 NAOXOYIhRNmk2ooSm6fA1DLX4c4iJqfzTJZimwtQf9pxpxTaVlO1ZJzxbtYHU38qQejitAKGfQ3 IWbA8CU/knFo/AfbUaLyq9kquDmkJcmSfpbKAPDVIS5jOEZuU4CrtxVlzMdZjgiU42QBDrF27mG z7l2miBk6EDBiET5tn6Be5PLgxYaUGf01EVsmzWl5P9A/kr6nIaSRbdP19NJeMZyZx7uUNmuQb9 uVmrRJlBVHHBgfXisF80J4RhJwca3P64pBu+0JJylVcUg0xKtU9gpJSnhe0wxSmJa1Ija8hoLYD CKLAEF9CWu0yYuC3wpH629Oy+2WLWDLdd8S3Ndqps48CELbXATw== X-Received: by 2002:a05:600c:6812:b0:47e:e2ec:995b with SMTP id 5b1f17b1804b1-4805ce4d0damr73864745e9.9.1769430398528; Mon, 26 Jan 2026 04:26:38 -0800 (PST) X-Received: by 2002:a05:600c:6812:b0:47e:e2ec:995b with SMTP id 5b1f17b1804b1-4805ce4d0damr73864555e9.9.1769430398086; Mon, 26 Jan 2026 04:26:38 -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-4804d84589bsm273181895e9.3.2026.01.26.04.26.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 04:26:37 -0800 (PST) Message-ID: <99371939-e9b2-4114-8e27-e605ebf941de@redhat.com> Date: Mon, 26 Jan 2026 13:26:34 +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> Content-Language: en-US, fr From: Jocelyn Falempe In-Reply-To: <2026012642-threefold-atypical-a3ad@gregkh> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 >