From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752366AbcDZOh6 (ORCPT <rfc822;w@1wt.eu>);
	Tue, 26 Apr 2016 10:37:58 -0400
Received: from mga04.intel.com ([192.55.52.120]:34319 "EHLO mga04.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752416AbcDZOg0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2016 10:36:26 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.24,536,1455004800"; 
   d="scan'208";a="92226167"
From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>, linux-kernel@vger.kernel.org,
        vince@deater.net, eranian@google.com,
        Arnaldo Carvalho de Melo <acme@infradead.org>,
        Mathieu Poirier <mathieu.poirier@linaro.org>
Subject: Re: [PATCH v1 4/5] perf: Introduce address range filtering
In-Reply-To: <20160425142506.GJ3430@twins.programming.kicks-ass.net>
References: <1461251823-12416-1-git-send-email-alexander.shishkin@linux.intel.com> <1461251823-12416-5-git-send-email-alexander.shishkin@linux.intel.com> <20160422074555.GB3448@twins.programming.kicks-ass.net> <87zisl8vls.fsf@ashishki-desk.ger.corp.intel.com> <20160425142506.GJ3430@twins.programming.kicks-ass.net>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Tue, 26 Apr 2016 17:35:32 +0300
Message-ID: <87fuu88mkr.fsf@ashishki-desk.ger.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Peter Zijlstra <peterz@infradead.org> writes:

> On Fri, Apr 22, 2016 at 07:19:11PM +0300, Alexander Shishkin wrote:
>> +/*
>> + * Address range filtering: limiting the data to certain
>> + * instruction address ranges. Filters are ioctl()ed to us from
>> + * userspace as ascii strings.
>> + *
>> + * Filter string format:
>> + *
>> + * ACTION SOURCE:RANGE_SPEC
>> + * where ACTION is one of the
>> + *  * "filter": limit the trace to this region
>> + *  * "start": start tracing from this address
>> + *  * "stop": stop tracing at this address/region;
>> + * SOURCE is either "file" or "kernel"
>> + * RANGE_SPEC is
>> + *  * for "kernel": <start address>[/<size>]
>> + *  * for "file":   <start address>[/<size>]@</path/to/object/file>
>
> SOURCE seems entirely redundant

So module support as it is done in kprobe doesn't seem very useful for
us, because all it does is symbol name resolution and pinning module
while the corresponding kprobe is on.

What I had in mind was more like specifying $module:$start/$end, which
will lay dormant till the module is loaded and will also go away once
the module is unloaded, but I'm not sure if I can even get away with
stuff like that.

So, for the time being I would like to keep it like so:

...
 * ACTION RANGE_SPEC
 * where ACTION is one of the
 *  * "filter": limit the trace to this region
 *  * "start": start tracing from this address
 *  * "stop": stop tracing at this address/region;
 * RANGE_SPEC is
 *  * for kernel addresses: <start address>[/<size>]
 *  * for object files:     <start address>[/<size>]@</path/to/object/file>
...

iow, dropping the SOURCE like you said and moving on.

Regards,
--
Alex