2020-01-21 05:57:02

by Alex Shi

Subject: [PATCH] tracing: remove unused ret

No body care the variable 'ret' in function unregister_field_var_hists,
better to remove it.

Signed-off-by: Alex Shi <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: [email protected]
---
kernel/trace/trace_events_hist.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index f62de5f43e79..0acfac95ca2a 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -5712,12 +5712,11 @@ static void unregister_field_var_hists(struct hist_trigger_data *hist_data)
struct trace_event_file *file;
unsigned int i;
char *cmd;
- int ret;

for (i = 0; i < hist_data->n_field_var_hists; i++) {
file = hist_data->field_var_hists[i]->hist_data->event_file;
cmd = hist_data->field_var_hists[i]->cmd;
- ret = event_hist_trigger_func(&trigger_hist_cmd, file,
+ event_hist_trigger_func(&trigger_hist_cmd, file,
"!hist", "hist", cmd);
}
}
--
1.8.3.1

2020-01-21 22:37:01

by Steven Rostedt

Subject: Re: [PATCH] tracing: remove unused ret

On Tue, 21 Jan 2020 13:54:43 +0800
Alex Shi <[email protected]> wrote:

> No body care the variable 'ret' in function unregister_field_var_hists,
> better to remove it.
>
> Signed-off-by: Alex Shi <[email protected]>
> Cc: Steven Rostedt <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: [email protected]
> ---
> kernel/trace/trace_events_hist.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
> index f62de5f43e79..0acfac95ca2a 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -5712,12 +5712,11 @@ static void unregister_field_var_hists(struct hist_trigger_data *hist_data)
> struct trace_event_file *file;
> unsigned int i;
> char *cmd;
> - int ret;
>
> for (i = 0; i < hist_data->n_field_var_hists; i++) {
> file = hist_data->field_var_hists[i]->hist_data->event_file;
> cmd = hist_data->field_var_hists[i]->cmd;
> - ret = event_hist_trigger_func(&trigger_hist_cmd, file,
> + event_hist_trigger_func(&trigger_hist_cmd, file,

I pulled in some of your other patches (removing unused macros), but
these that remove 'ret' I prefer not to take. Yes, we currently do not
use ret here, but the compiler will easily remove its existence. I'm
thinking if anything, we should report an error if they do return
something other than success.

-- Steve



> "!hist", "hist", cmd);
> }
> }

2020-02-04 11:12:26

by Alex Shi

Subject: Re: [PATCH] tracing: remove unused ret

?? 2020/1/22 ????6:35, Steven Rostedt д??:
> On Tue, 21 Jan 2020 13:54:43 +0800
> Alex Shi <[email protected]> wrote:
>
>> No body care the variable 'ret' in function unregister_field_var_hists,
>> better to remove it.
>>
>> Signed-off-by: Alex Shi <[email protected]>
>> Cc: Steven Rostedt <[email protected]>
>> Cc: Ingo Molnar <[email protected]>
>> Cc: [email protected]
>> ---
>> kernel/trace/trace_events_hist.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
>> index f62de5f43e79..0acfac95ca2a 100644
>> --- a/kernel/trace/trace_events_hist.c
>> +++ b/kernel/trace/trace_events_hist.c
>> @@ -5712,12 +5712,11 @@ static void unregister_field_var_hists(struct hist_trigger_data *hist_data)
>> struct trace_event_file *file;
>> unsigned int i;
>> char *cmd;
>> - int ret;
>>
>> for (i = 0; i < hist_data->n_field_var_hists; i++) {
>> file = hist_data->field_var_hists[i]->hist_data->event_file;
>> cmd = hist_data->field_var_hists[i]->cmd;
>> - ret = event_hist_trigger_func(&trigger_hist_cmd, file,
>> + event_hist_trigger_func(&trigger_hist_cmd, file,
>
> I pulled in some of your other patches (removing unused macros), but
> these that remove 'ret' I prefer not to take. Yes, we currently do not
> use ret here, but the compiler will easily remove its existence. I'm
> thinking if anything, we should report an error if they do return
> something other than success.
>
> -- Steve
>

Pretty make sense. :)

Thanks!
Alex