Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp5127763imd; Tue, 30 Oct 2018 12:23:28 -0700 (PDT) X-Google-Smtp-Source: AJdET5erBU/QmkJEQtBEWyKpn+xibrhnygdFO1s7nufXEm5rvDkze8A5bfAYa79DM9zxsHtUmxnp X-Received: by 2002:a65:4208:: with SMTP id c8-v6mr135879pgq.335.1540927408622; Tue, 30 Oct 2018 12:23:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540927408; cv=none; d=google.com; s=arc-20160816; b=YGE5A6WyuRvX0U0jbt3vMCKIkgp627lY5+3CQmTtPD4j0mGmcW2WeWfTEoDKHFXUvN NGopqnjgnORkmLSuujvOVfwOaU6x38Xb4NM/6l05jXmpJ+VSXQ1mRZKRKGYQ1afDK0fs pzbCiAwfoefADleWRBjmBAC2rC7hSyZDxx8xDL8MWlVQoy5UrBxbMHp4xphXNZCDxqH5 RbqpLrlR0KP8l0LJD5mOkAnPiJ8mskJrv6Q+y34S8P2LhS4d5TMkb3waUhyf9jwL5uOW UmxYS3HIwZ6Sz28pEmtbrj78DxgkCdcqs/oMKw5rzZY5ucBTgDaebGcQkwrgZe5IwOrn zxKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=rJ/LXdOZtOzEydIuzo4iyP3H5JJsCNGO3j3myWTWRkg=; b=MNJIu/PEGfRZ4DnsdgFkFTOwon9fePapJIWObemwYdN2cMgYZRw/0RJYeFChF925nj O+VpIi1sKCODs8GqoLITbfY4X1rLHnkz4SxBBq+4eAj14EfHdvEtLrGqLR5LsUqcPZw6 1mFzpPCgJPVjKaMXq/1KiILSfedbOMUcwlTNItxgZSij8rr56vrBZ9yzIffWUGKao0dt OvuFOXRmBHFQ/FLHz60Whg68SGMKuRsykSO6HdMmEUs8+hSWkkmxJYJRZrE07cU6N2vH sKomVZu4fl3rjZtBq6U5FrnKAHjOnw2unS6RQVWxrxB+xByznfhRSWwFZ2eUpS548WvG I33g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e1-v6si25027931pgd.528.2018.10.30.12.23.12; Tue, 30 Oct 2018 12:23:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727948AbeJaDwq (ORCPT + 99 others); Tue, 30 Oct 2018 23:52:46 -0400 Received: from mx2.suse.de ([195.135.220.15]:37066 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727679AbeJaDwq (ORCPT ); Tue, 30 Oct 2018 23:52:46 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 04CADAB4D; Tue, 30 Oct 2018 18:58:03 +0000 (UTC) Date: Tue, 30 Oct 2018 11:57:56 -0700 From: Davidlohr Bueso To: Vito Caputo Cc: Waiman Long , akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Davidlohr Bueso Subject: Re: [PATCH] fs/proc: introduce /proc/stat2 file Message-ID: <20181030185756.w3f2trelb7nikgmk@linux-r8p5> References: <20181029192521.23059-1-dave@stgolabs.net> <0afed890-7c5a-93ee-cdb9-e30775bd9cf1@redhat.com> <20181029200050.iejuxckzbm742dmw@linux-r8p5> <3c5ba85b-5114-c751-0114-ac2cb64c02ea@redhat.com> <20181029203818.pot26ewxbncfrnua@linux-r8p5> <20181029212314.nwruqg6au23ebqlu@shells.gnugeneration.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20181029212314.nwruqg6au23ebqlu@shells.gnugeneration.com> User-Agent: NeoMutt/20180323 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 29 Oct 2018, Vito Caputo wrote: >I'm definitely not in favor of just adding another stat file that is the >same format as the existing one with the intrs zeroed out. It's a dirty >hack; fine for your local needs but too gross for upstream IMHO. I suspect very few users of /proc/stat actually use the irq fields in the first place. So the common case ends up doing unnecessary operations. The stat2 approach is not perfect, but I think it's the best approach so far. This sort of renaming is not uncommon when we cannot break userspace, and its not like procfs is not already far contaminated already. There are not enough users that care about this stuff, afaik. What you suggest sounds like a lot of over-engineering. Thanks, Davidlohr