From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753569AbcHRGcx (ORCPT ); Thu, 18 Aug 2016 02:32:53 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:42494 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751255AbcHRGcw (ORCPT ); Thu, 18 Aug 2016 02:32:52 -0400 Date: Thu, 18 Aug 2016 07:32:39 +0100 From: Al Viro To: Janani Ravichandran Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, riel@surriel.com, akpm@linux-foundation.org, vdavydov@virtuozzo.com, mhocko@suse.com, vbabka@suse.cz, mgorman@techsingularity.net, kirill.shutemov@linux.intel.com, bywxiaobai@163.com Subject: Re: [PATCH v2 2/2] fs: super.c: Add tracepoint to get name of superblock shrinker Message-ID: <20160818063239.GO2356@ZenIV.linux.org.uk> References: <600943d0701ae15596c36194684453fef9ee075e.1471496833.git.janani.rvchndrn@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <600943d0701ae15596c36194684453fef9ee075e.1471496833.git.janani.rvchndrn@gmail.com> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 18, 2016 at 02:09:31AM -0400, Janani Ravichandran wrote: > static LIST_HEAD(super_blocks); > @@ -64,6 +65,7 @@ static unsigned long super_cache_scan(struct shrinker *shrink, > long inodes; > > sb = container_of(shrink, struct super_block, s_shrink); > + trace_mm_shrinker_callback(shrink, sb->s_type->name); IOW, we are (should that patch be accepted) obliged to keep the function in question and the guts of struct shrinker indefinitely. NAK. Keep your debugging patches in your tree and maintain them yourself. And if a change in the kernel data structures breaks them (and your userland code relying on those), it's your problem. Tracepoints are very nice for local debugging/data collection/etc. patches. Accepting them into mainline shifts the responsibility for updating them to the rest of us, and unlike you we can't update the userland side. Adding a userland ABI means pledging to keep it alive pretty much indefinitely. It's not automatically unacceptable (hell, new syscalls get added from time to time), but it should come with a serious analysis of what's getting exposed and it shouldn't be accepted without such.