From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31D71C3DA6E for ; Thu, 28 Dec 2023 10:17:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 998D98D0010; Thu, 28 Dec 2023 05:17:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 948EC8D000F; Thu, 28 Dec 2023 05:17:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 810878D0010; Thu, 28 Dec 2023 05:17:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6FB9E8D000F for ; Thu, 28 Dec 2023 05:17:49 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3F4FC1C10EB for ; Thu, 28 Dec 2023 10:17:49 +0000 (UTC) X-FDA: 81615825858.22.9F7D0F1 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf07.hostedemail.com (Postfix) with ESMTP id 265F440013 for ; Thu, 28 Dec 2023 10:17:46 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=Mzksk20R; spf=pass (imf07.hostedemail.com: domain of gregkh@linuxfoundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703758667; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=uH79pfWVr8Lkojm+daV4C7eQ2tXTUpbnbMVNRWV6dAA=; b=uzq0AytwaN+4Zu2aV31Qi47A9pRd5UWP2UGvYSMDt6x68LeY7u4mxlwjm87N5NicTt6ZPE 3f1uA2FKUMWE//gkhtJ2O47PlbiDoqvAIyUnXbK7ekwlL6fMza5qiL8EvlS7Bw717bQAdT qXGLg8BjtWxZr9yjmgkPLpb+zy+w3Qc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703758667; a=rsa-sha256; cv=none; b=pJXMDnBXuSeAybUT7miB2xjsOWsJGNWFgnYcN0Favv9UE93OSCTpmztvbX5lgkSPZ4r8e7 +2w63h41rC5d7PQY2eg31b+ayED0Xa/3dKNaAN6BZaZjYaucBqLVCDjc4f71gOTQHzEVg0 Eyd2MuMoYQ47w1p9/xAYhmm6Zc3cY6o= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=Mzksk20R; spf=pass (imf07.hostedemail.com: domain of gregkh@linuxfoundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 9766FCE1409; 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13e5fbd4-d84d-faba-47f1-d0024d2c572d@google.com> X-Stat-Signature: hnn6b9c4xjwct3u5taoesnpejb9jhyeh X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 265F440013 X-Rspam-User: X-HE-Tag: 1703758666-128541 X-HE-Meta: U2FsdGVkX194gqcvhus/JJ5Y3RiB4iQtXvinL6BNzxSYOBbppENQwfeVv1/um+/sVZi+Ku2QQn8vsiw0rY4bqC6XbXB9OZWSOFp+gYCzUAhfk6JHGWFWcw+rhdP2qwFTZISmldZ3HCLQbDC/FK/rpYTqdx1ZFJf0BVyX5ufiF2ZkMxJ4It/X4D0XRfR3ovnAUQmS5SHuVfBSQRZYp7/qtvBsklDtSYiWQsIgAN58uknP5/F7giiJGNPKf48VKLLwTrilyWhZZcBqGL9+6pMDK7n7JpPlYHkEl2rIlTBEbMnpvrbw7FOKJNAdYLfuG/vPtKmR9V48TkqCh2+f0dMD0ErIPE8XIidi68l+85Pupeg9m0/wfhSXvblFDw1Mc8kkDcF780pdYugE5LIEhSgfi6mgqp811Q6o88TZPTN1Gd7xKeY/d3ueKRXPLHvXf5P5q/D7iVfwkYx7qoeyegC2Ez2jSfASD41LPowQMAszD5I0cBh9M10kPfS05sAE9iIoeZMl9bVO+B6Nswc3XR+XBp9VeoawxdGX3YIH1MRW8X8Gc0GK4gebt13jIdHhvxq1bwR0OZATko1e7OUUspjk5YtE6RAtgqwVg1QE8gh70doJ6K0UM2zrysIMZea1cmInSP4kwyrgtRw2YVPKwKsB+jv722rZzhmCH4FA5Wk/cI/wCLuxTCKgpGxKjwpoJ33kzyDU2Vk2WCR7Mid4AnPpSTuBN4+NbYWMxelFaC3GuESYNZXUBKw3yFzHbeGpqjdms5I+CtTMTFKVCEP36i633I5dnOAMPPn7vtrJntRJ2KUwFCNhq0D3mW9H0YRuwU9DB1vUgGW+WVJ3fZs4DYIt3IhES2iOvgTqzzc01zeeqEhn3eo9Sw7tvAk7Unau3iLWyycdbKWOLXmfv/zuS8XCFcgyq1cZjZlYOKZPtgPTDBzgL55P82AoLYPvVilxxBz/pf81hnwHn3lffWz+Z+5 kttQn0P8 CIP6dVmNt6Any/eKfp3vokPGP8eNsPGxCjF57dX3wfCsKtj7WppUy539avb5S6UcBKo4ASoWXtALfgdVIjCZSegrUiKMUYZ3Mfgub48wSOAYmNjvQvWDZ/jLusebC4L8vAAThMIyHOc1rawGt2hTPLHU0xT2G32RkYdTKdl/LZMZOmoOBmxzVusVtvvPvlklto/FpBR/r713jPkTMj3Mx0tF0FQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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