Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp3859092rdb; Thu, 28 Dec 2023 02:17:47 -0800 (PST) X-Google-Smtp-Source: AGHT+IEuXqpTV33myulEmtChTZ/SPjgSw8PJTulWo+in1Bjp9sUuYaklLTpANEPxeukNERGbk/Vj X-Received: by 2002:a05:620a:28c9:b0:781:5c46:22dd with SMTP id l9-20020a05620a28c900b007815c4622ddmr3273098qkp.47.1703758667257; Thu, 28 Dec 2023 02:17:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703758667; cv=none; d=google.com; s=arc-20160816; b=lYY6cxcjO1mffJXKLFwIWceh7BnF6u5Ga29yPQ9PzBZNALkjy+eRGkPz83Mf1XM/CC hECXHGfiNBkvRO10DicBdWUkbGlygb/uexK0mim7eW3CW88TtqJVtZWLBJ7N7d88/hdF 4OniKLisqHAG7GPtpA0t/lAdGGdr5LJbDivlnvWSBkLDSduS2l8r7QFkjs01IuwYHhdj IM6o5ZqDUoLz7UEfqgk2kSxtrMMHz4NNhvjTAkZXYrsBzPtdylygWK/vIrc8QWuECftr RCO1z2RdDTssjxuN1c1LNG9lsmvxNliA4TB9xiKVvXmAp8eiR5s09vhNM6Amy+WsNhlQ TBRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=uH79pfWVr8Lkojm+daV4C7eQ2tXTUpbnbMVNRWV6dAA=; fh=BM0S8ts+abnHUwZcMsSRIjb+mt0xRfeHxMONnfkn/c0=; b=jbB65XHnZPA9QDgcbI3irxOTx+H6OZJfsAzGmc5qL/+dwO0T4lflsnrB6vgI8lcf1s oxqoMbwMQ+lXzYiftPVmtx6PRNaKy3TKyekuvBVuVT0Efra++Eny5ka9yoKOcxxo0HcM aj7Fp7aptb+bOc+hwIkt+LHwUPNlL/E3+QQAXQnUjqQYol8rtZKrmJKQEhLeQuN4pzVH DXeGArwyg27iP49xltwQoyvAfidpeNS45uTYMFUarIPThFd5xySQllbUa8kh44SyQXw7 Awh1QpJXnwkOEj2nVavbzuSKu9kDrwD6xinMY6w5KoZT5wUrNZs5kOdfAFGfB5Mhu8Jd GpaA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Mzksk20R; spf=pass (google.com: domain of linux-kernel+bounces-12561-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-12561-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id z12-20020ae9c10c000000b007815e0763e0si3505343qki.341.2023.12.28.02.17.47 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Dec 2023 02:17:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-12561-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Mzksk20R; spf=pass (google.com: domain of linux-kernel+bounces-12561-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-12561-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 06E891C231D0 for ; Thu, 28 Dec 2023 10:17:47 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 63E956AB0; Thu, 28 Dec 2023 10:17:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="Mzksk20R" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 5B7F363C6 for ; Thu, 28 Dec 2023 10:17:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66A93C433C7; Thu, 28 Dec 2023 10:17:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1703758659; bh=E52uTUo/hljsQwQ023swY2xZdyNV3GH52IXVtrNIF48=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Mzksk20R7PZW9oY90SUixy6imTJzFkT8Uhv47wEow8bwfucNfgXandFSuzcOJQBEG Tn7Gf3x9giWfziUCRlXayNqfcoo3EHo0ZZ8Fe8miQpA7jqwKMkCRNqGbncxk6cOqd2 Tkb9oSoRGJkZUQYCo0lOmG95mm+IKWNE76rJ+3RA= Date: Thu, 28 Dec 2023 10:17:37 +0000 From: Greg Kroah-Hartman To: David Rientjes Cc: Pasha Tatashin , Linus Torvalds , rafael@kernel.org, Andrew Morton , surenb@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, souravpanda@google.com Subject: Re: Sysfs one-value-per-file (was Re: [PATCH] vmstat: don't auto expand the sysfs files) Message-ID: <2023122824-washout-shrubs-1d6d@gregkh> References: <20231211154644.4103495-1-pasha.tatashin@soleen.com> <3d415ab4-e8c7-7e72-0379-952370612bdd@google.com> <13e5fbd4-d84d-faba-47f1-d0024d2c572d@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13e5fbd4-d84d-faba-47f1-d0024d2c572d@google.com> On Tue, Dec 26, 2023 at 04:53:31PM -0800, David Rientjes wrote: > I'd argue that the ship on the "sysfs one-value-per-file rule" has sailed > for long-standing use cases where either (1) switching is just not > possible or (2) switching would be an undue burden to the user. > > An example of (1) would be THP enablement and defrag options: > > $ grep . /sys/kernel/mm/transparent_hugepage/{defrag,enabled,shmem_enabled} > /sys/kernel/mm/transparent_hugepage/defrag:always defer defer+madvise [madvise] never > /sys/kernel/mm/transparent_hugepage/enabled:[always] madvise never > /sys/kernel/mm/transparent_hugepage/shmem_enabled:always within_size advise [never] deny force > > This convention isn't going to change. We're not going to suddenly add a > new enablement or defrag option that can only be set in a newly added > file that is one-value-per-file. > > THP was obviously introduced before any sysfs "one-value-per-file rule" No, the rule has been there since "day one" for sysfs, this file snuck in much later with no one noticing it against the "rules" and I've been complaining about it every time someone tries to add a new field to it that I notice. > and, in retrospect, I think most people would agree that these files would > be much better off implemented returning a single word. But, choices > where made in the "before times", and it was implemented in a way that > shows all the possible choices and which one is in effect. Owell. We > deal with it, and we move on. > > Imagine if I add a new choice of "lightweight" to the "defrag" file. The > only rational way to do that would be to extend the current interface, not > create a new /sys/kernel/mm/transparent_hugepage/defrag/lightweight file > that is one-value-per-file that unsets all the other options in "defrag." > Please. Please remember that the sysfs rule is there for a good reason, it makes it very hard to break existing userspace tools if you stick with it. If you decide to ignore that rule, then you are on your own and better make sure that nothing breaks. Again, please learn from our previous mistakes with proc files, that is why the rule is there. If you wish to ignore the rule, you all really are on your own, good luck! greg k-h