On 17 January 2018 at 05:31, Alexander Shishkin
wrote:
> On Tue, Feb 07, 2017 at 10:50:50AM -0700, Mathieu Poirier wrote:
>> > index 39106ae61b..d7a11faac1 100644
>> > --- a/kernel/events/core.c
>> > +++ b/kernel/events/core.c
>> > @@ -8194,7 +8194,8 @@ static
On 17 January 2018 at 05:31, Alexander Shishkin
wrote:
> On Tue, Feb 07, 2017 at 10:50:50AM -0700, Mathieu Poirier wrote:
>> > index 39106ae61b..d7a11faac1 100644
>> > --- a/kernel/events/core.c
>> > +++ b/kernel/events/core.c
>> > @@ -8194,7 +8194,8 @@ static void
On 18 January 2018 at 10:06, Will Deacon wrote:
> On Thu, Jan 18, 2018 at 09:59:26AM -0700, Mathieu Poirier wrote:
>> On 17 January 2018 at 05:31, Alexander Shishkin
>> wrote:
>> > On Tue, Feb 07, 2017 at 10:50:50AM -0700, Mathieu Poirier
On 18 January 2018 at 10:06, Will Deacon wrote:
> On Thu, Jan 18, 2018 at 09:59:26AM -0700, Mathieu Poirier wrote:
>> On 17 January 2018 at 05:31, Alexander Shishkin
>> wrote:
>> > On Tue, Feb 07, 2017 at 10:50:50AM -0700, Mathieu Poirier wrote:
>> >> > index 39106ae61b..d7a11faac1 100644
>> >>
On Thu, Jan 18, 2018 at 09:59:26AM -0700, Mathieu Poirier wrote:
> On 17 January 2018 at 05:31, Alexander Shishkin
> wrote:
> > On Tue, Feb 07, 2017 at 10:50:50AM -0700, Mathieu Poirier wrote:
> >> > index 39106ae61b..d7a11faac1 100644
> >> > ---
On Thu, Jan 18, 2018 at 09:59:26AM -0700, Mathieu Poirier wrote:
> On 17 January 2018 at 05:31, Alexander Shishkin
> wrote:
> > On Tue, Feb 07, 2017 at 10:50:50AM -0700, Mathieu Poirier wrote:
> >> > index 39106ae61b..d7a11faac1 100644
> >> > --- a/kernel/events/core.c
> >> > +++
On 17 January 2018 at 05:31, Alexander Shishkin
wrote:
> On Tue, Feb 07, 2017 at 10:50:50AM -0700, Mathieu Poirier wrote:
>> > index 39106ae61b..d7a11faac1 100644
>> > --- a/kernel/events/core.c
>> > +++ b/kernel/events/core.c
>> > @@ -8194,7 +8194,8 @@ static
On 17 January 2018 at 05:31, Alexander Shishkin
wrote:
> On Tue, Feb 07, 2017 at 10:50:50AM -0700, Mathieu Poirier wrote:
>> > index 39106ae61b..d7a11faac1 100644
>> > --- a/kernel/events/core.c
>> > +++ b/kernel/events/core.c
>> > @@ -8194,7 +8194,8 @@ static void
On 2 February 2017 at 09:22, Alexander Shishkin
wrote:
> Mathieu Poirier writes:
>
>> If this is what you want to convey then
>>
>> + * @action:filter/start/stop
>>
>> needs to be fixed. This can be interpreted as "use range
On 2 February 2017 at 09:22, Alexander Shishkin
wrote:
> Mathieu Poirier writes:
>
>> If this is what you want to convey then
>>
>> + * @action:filter/start/stop
>>
>> needs to be fixed. This can be interpreted as "use range filter,
>> start filter or stop filter" - which is exactly what I
On 2 February 2017 at 03:42, Alexander Shishkin
wrote:
> Mathieu Poirier writes:
>
>> Do we have two different syntax to specify the same behaviour?
>>
>> For example we have:
>>
>> --filter 'start 0x80082570/0x644'
>>
>> and
>>
>>
On 2 February 2017 at 03:42, Alexander Shishkin
wrote:
> Mathieu Poirier writes:
>
>> Do we have two different syntax to specify the same behaviour?
>>
>> For example we have:
>>
>> --filter 'start 0x80082570/0x644'
>>
>> and
>>
>> --filter 'filter 0x80082570/0x644'
>>
>> Both will end up with
Mathieu Poirier writes:
> If this is what you want to convey then
>
> + * @action:filter/start/stop
>
> needs to be fixed. This can be interpreted as "use range filter,
> start filter or stop filter" - which is exactly what I did. Something
> like
I was
Mathieu Poirier writes:
> If this is what you want to convey then
>
> + * @action:filter/start/stop
>
> needs to be fixed. This can be interpreted as "use range filter,
> start filter or stop filter" - which is exactly what I did. Something
> like
I was beginning to think that the
Mathieu Poirier writes:
> Do we have two different syntax to specify the same behaviour?
>
> For example we have:
>
> --filter 'start 0x80082570/0x644'
>
> and
>
> --filter 'filter 0x80082570/0x644'
>
> Both will end up with filter->filter == 1 and filter->range == 1.
Mathieu Poirier writes:
> Do we have two different syntax to specify the same behaviour?
>
> For example we have:
>
> --filter 'start 0x80082570/0x644'
>
> and
>
> --filter 'filter 0x80082570/0x644'
>
> Both will end up with filter->filter == 1 and filter->range == 1.
This is another reason why
On 1 February 2017 at 14:33, Mathieu Poirier wrote:
> )
>
> On 1 February 2017 at 05:46, Alexander Shishkin
> wrote:
>> Mathieu Poirier writes:
>>
>>> On 27 January 2017 at 05:12, Alexander Shishkin
>>>
On 1 February 2017 at 14:33, Mathieu Poirier wrote:
> )
>
> On 1 February 2017 at 05:46, Alexander Shishkin
> wrote:
>> Mathieu Poirier writes:
>>
>>> On 27 January 2017 at 05:12, Alexander Shishkin
>>> wrote:
But "range" is not an action, it's a type of a filter. It determines the
)
On 1 February 2017 at 05:46, Alexander Shishkin
wrote:
> Mathieu Poirier writes:
>
>> On 27 January 2017 at 05:12, Alexander Shishkin
>> wrote:
>>> But "range" is not an action, it's a type of
)
On 1 February 2017 at 05:46, Alexander Shishkin
wrote:
> Mathieu Poirier writes:
>
>> On 27 January 2017 at 05:12, Alexander Shishkin
>> wrote:
>>> But "range" is not an action, it's a type of a filter. It determines the
>>> condition that triggers an action. An action, however, is what we
Mathieu Poirier writes:
> On 27 January 2017 at 05:12, Alexander Shishkin
> wrote:
>> But "range" is not an action, it's a type of a filter. It determines the
>> condition that triggers an action. An action, however, is what we do
Mathieu Poirier writes:
> On 27 January 2017 at 05:12, Alexander Shishkin
> wrote:
>> But "range" is not an action, it's a type of a filter. It determines the
>> condition that triggers an action. An action, however, is what we do
>> when the condition comes true.
>
> Then filter->action could
On 27 January 2017 at 05:12, Alexander Shishkin
wrote:
> Mathieu Poirier writes:
>
>> Hi Alex,
>
> Hi Mathieu,
>
>> This changes the behavior we used to have. Now a range filter with a size
>> of 0
>> will be treated as start
On 27 January 2017 at 05:12, Alexander Shishkin
wrote:
> Mathieu Poirier writes:
>
>> Hi Alex,
>
> Hi Mathieu,
>
>> This changes the behavior we used to have. Now a range filter with a size
>> of 0
>> will be treated as start filter rather than an error. See below on a
>> possible
>> way of
Mathieu Poirier writes:
> Hi Alex,
Hi Mathieu,
> This changes the behavior we used to have. Now a range filter with a size of > 0
> will be treated as start filter rather than an error. See below on a possible
> way of fixing this.
Not really. Currently we have 2
Mathieu Poirier writes:
> Hi Alex,
Hi Mathieu,
> This changes the behavior we used to have. Now a range filter with a size of > 0
> will be treated as start filter rather than an error. See below on a possible
> way of fixing this.
Not really. Currently we have 2 drivers using this and both
Hi Alex,
On Thu, Jan 26, 2017 at 11:40:55AM +0200, Alexander Shishkin wrote:
> This is a cosmetic patch that deals with the address filter structure's
> ambiguous fields 'filter' and 'range'. The former stands to mean that the
> filter's *action* should be to filter the traces to its address
Hi Alex,
On Thu, Jan 26, 2017 at 11:40:55AM +0200, Alexander Shishkin wrote:
> This is a cosmetic patch that deals with the address filter structure's
> ambiguous fields 'filter' and 'range'. The former stands to mean that the
> filter's *action* should be to filter the traces to its address
kbuild test robot writes:
> Hi Alexander,
>
> [auto build test ERROR on tip/perf/core]
> [also build test ERROR on v4.10-rc5 next-20170125]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
>
kbuild test robot writes:
> Hi Alexander,
>
> [auto build test ERROR on tip/perf/core]
> [also build test ERROR on v4.10-rc5 next-20170125]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
>
Hi Alexander,
[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.10-rc5 next-20170125]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Alexander,
[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.10-rc5 next-20170125]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
This is a cosmetic patch that deals with the address filter structure's
ambiguous fields 'filter' and 'range'. The former stands to mean that the
filter's *action* should be to filter the traces to its address range if
it's set or stop tracing if it's unset. This is confusing and hard on the
eyes,
This is a cosmetic patch that deals with the address filter structure's
ambiguous fields 'filter' and 'range'. The former stands to mean that the
filter's *action* should be to filter the traces to its address range if
it's set or stop tracing if it's unset. This is confusing and hard on the
eyes,
34 matches
Mail list logo