linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladislav Valtchev <vladislav.valtchev@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, y.karadz@gmail.com
Subject: Re: [PATCH 08/11] trace-cmd: Making start,extract,stream,profile separate funcs
Date: Tue, 28 Nov 2017 20:34:22 +0200	[thread overview]
Message-ID: <1511894062.1754.21.camel@gmail.com> (raw)
In-Reply-To: <20171128121450.32db5781@gandalf.local.home>

On Tue, 2017-11-28 at 12:14 -0500, Steven Rostedt wrote:	
> As everything is doing both init_common_record_context() and
> parse_record_options() why not just move the
> init_common_record_context() into parse_record_options(). If you need
> to do something special (like set events = 1 for profile) have that
> done in parse_record_options() if the cmd is CMD_record. Yes, you need
> to pass the CMD_* to parse_record_options() in this case.
> 

Actually, I spent some effort trying to avoid exactly that:
"if" statments in "overly generic code". In my view, the point
of having several trace_* functions is to be able to write specific code
for them, without conditional branches.

I understand that, clearly, there is a trade-off because the extreme of that is to
have a different copy of a function like parse_record_options() for each command.
On the other hand, when you have an IF (cmd is PROFILE) at the beginning and an
if (cmd is PROFILE) at the end, it looks to me a good thing to move that code in the 
specific trace_profile() function. It's all about finding the right balance:
the previous extreme (before the refactoring) was to have everything in trace_record()
with much more if statements and that looked more complicated to follow, at least for me.

Clearly, I fully understand that the location of that "right balance" is pretty subjective.

Do you have a strong opinion on that?


Vlad

  reply	other threads:[~2017-11-28 18:34 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-23 16:33 [PATCH 00/11] trace-cmd: Refactoring trace_record() Vladislav Valtchev (VMware)
2017-11-23 16:33 ` [PATCH 01/11] trace-cmd: Extract trace_stop() from trace_record() Vladislav Valtchev (VMware)
2017-11-23 16:33 ` [PATCH 02/11] trace-cmd: Extract trace_restart() " Vladislav Valtchev (VMware)
2017-11-23 16:33 ` [PATCH 03/11] trace-cmd: Extract trace_reset() " Vladislav Valtchev (VMware)
2017-11-23 16:33 ` [PATCH 04/11] trace-cmd: Extract parse_record_options() " Vladislav Valtchev (VMware)
2017-11-28 16:48   ` Steven Rostedt
2017-11-28 18:17     ` Vladislav Valtchev
2017-11-28 18:30       ` Steven Rostedt
2017-11-28 18:57         ` Vladislav Valtchev
2017-11-28 19:15           ` Steven Rostedt
2017-11-29 14:53       ` Steven Rostedt
2017-11-29 15:18         ` Vladislav Valtchev
2017-11-23 16:33 ` [PATCH 05/11] trace-cmd: Rename trace_profile() to trace_profile_int() Vladislav Valtchev (VMware)
2017-11-28 17:05   ` Steven Rostedt
2017-11-28 19:00     ` Vladislav Valtchev
2017-11-23 16:33 ` [PATCH 06/11] trace-cmd: Replacing cmd flags w/ a trace_cmd enum Vladislav Valtchev (VMware)
2017-11-23 16:33 ` [PATCH 07/11] trace-cmd: Extracting record_trace() Vladislav Valtchev (VMware)
2017-11-23 16:33 ` [PATCH 08/11] trace-cmd: Making start,extract,stream,profile separate funcs Vladislav Valtchev (VMware)
2017-11-28 17:14   ` Steven Rostedt
2017-11-28 18:34     ` Vladislav Valtchev [this message]
2017-11-28 19:35       ` Steven Rostedt
2017-11-29 10:03         ` Vladislav Valtchev
2017-11-29 12:48           ` Steven Rostedt
2017-11-23 16:33 ` [PATCH 09/11] trace-cmd: Consolidate ARRAY_SIZE() in trace-cmd.h Vladislav Valtchev (VMware)
2017-11-28 17:16   ` Steven Rostedt
2017-11-23 16:33 ` [PATCH 10/11] trace-cmd: Making the "die" functions noreturn Vladislav Valtchev (VMware)
2017-11-23 16:33 ` [PATCH 11/11] trace-cmd: Introducing get_trace_cmd_type() Vladislav Valtchev (VMware)
2017-11-28 17:17   ` Steven Rostedt
2017-11-28 18:32     ` Steven Rostedt
2017-11-28 19:04       ` Vladislav Valtchev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1511894062.1754.21.camel@gmail.com \
    --to=vladislav.valtchev@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=y.karadz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).