Linux DTrace development list
 help / color / mirror / Atom feed
From: Kris Van Hees <kris.van.hees@oracle.com>
To: eugene.loh@oracle.com
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [DTrace-devel] [PATCH 02/14] Clean up prp/uprp variable names
Date: Tue, 4 Jun 2024 14:44:59 -0400	[thread overview]
Message-ID: <Zl9gqz2tK+BdRRSf@oracle.com> (raw)
In-Reply-To: <20240604181113.11505-3-eugene.loh@oracle.com>

On Tue, Jun 04, 2024 at 02:11:01PM -0400, eugene.loh--- via DTrace-devel wrote:
> From: Eugene Loh <eugene.loh@oracle.com>
> 
> Should prp be oprp?  Or should we use opr and upr?

This does not belong in the commit message.  But yes, we should stick with
prp for the overlying probe, which is consistent with the rest of the code
base.

Also, I think this patch should address a few other issues in this file, e.g.
making sure comments are consistent with the code (e.g. if it mentions we are
creating overlying and underlying probe lists, the code should also create
tgem in that order - or the comment ought to be updated to match the code
order).  etc...

> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> ---
>  libdtrace/dt_prov_uprobe.c | 55 +++++++++++++++++++++++++++-----------
>  1 file changed, 40 insertions(+), 15 deletions(-)
> 
> diff --git a/libdtrace/dt_prov_uprobe.c b/libdtrace/dt_prov_uprobe.c
> index afc1f628..cace406d 100644
> --- a/libdtrace/dt_prov_uprobe.c
> +++ b/libdtrace/dt_prov_uprobe.c
> @@ -6,6 +6,31 @@
>   *
>   * The uprobe-based provider for DTrace (implementing pid and USDT providers).
>   */
> +/*
> + * This file uses both overlying probes (specified by the user) as well as
> + * underlying probes (the uprobes recognized by the kernel).  To minimize
> + * confusion, this file should use consistent variable names:
> + *
> + *     dt_probe_t	*prp;   //  overlying probe
> + *     dt_probe_t	*uprp;  // underlying probe
> + *
> + *             Either one might be returned by dt_probe_lookup() or
> + *             dt_probe_insert() or added to dt_enablings[] or dt_probes[].
> + *             Further, uprp might be returned by create_underlying().
> + *
> + *     dt_uprobe_t	*upp;   // uprobe associated with an underlying probe
> + *
> + *     list_probe_t	*pop;   //  overlying probe list
> + *     list_probe_t	*pup;   // underlying probe list
> + *
> + * The provider-specific prv_data has these meanings:
> + *
> + *     prp->prv_data            // dt_list_t of associated underlying probes
> + *
> + *     uprp->prv_data           // upp (the associated uprobe)
> + *
> + * Finally, note that upp->probes is a dt_list_t of overlying probes.
> + */

This comment block is too verbose and I don't think it is really needed, if you
are going to rename variables anyway to be consistent based on your proposal
(as you do in this patch).  So, the comment becomes unnecessary by the patch
itself.

Even if we were to retain a comment like this, I think it should be much more
brief.  But again, I think the patch itself accomplishes all that is needed,
so no need to comment.

>  #include <sys/types.h>
>  #include <assert.h>
>  #include <errno.h>
> @@ -118,7 +143,7 @@ static dt_probe_t *create_underlying(dtrace_hdl_t *dtp,
>  	char			mod[DTRACE_MODNAMELEN];
>  	char			prb[DTRACE_NAMELEN];
>  	dtrace_probedesc_t	pd;
> -	dt_probe_t		*prp;
> +	dt_probe_t		*uprp;

I am OK with doing this renaming of variable name because you want some form
of consustency throughout this file, but I don't believe it is really needed.
This function only deals with one type of probes, identified both in the
comment and the function name as underlying probes.  So, the prp variable that
is used in many places in DTrace source code to denote a probe pointer should
not cause any confusion.

But if you want to change it, no problem.

>  	dt_uprobe_t		*upp;
>  	int			is_enabled = 0;
>  
> @@ -160,8 +185,8 @@ static dt_probe_t *create_underlying(dtrace_hdl_t *dtp,
>  	pd.fun = psp->pps_fun;
>  	pd.prb = prb;
>  
> -	prp = dt_probe_lookup(dtp, &pd);
> -	if (prp == NULL) {
> +	uprp = dt_probe_lookup(dtp, &pd);
> +	if (uprp == NULL) {
>  		dt_provider_t	*pvp;
>  
>  		/* Get the provider for underlying probes. */
> @@ -182,12 +207,12 @@ static dt_probe_t *create_underlying(dtrace_hdl_t *dtp,
>  		if (upp->tp == NULL)
>  			goto fail;
>  
> -		prp = dt_probe_insert(dtp, pvp, pd.prv, pd.mod, pd.fun, pd.prb,
> +		uprp = dt_probe_insert(dtp, pvp, pd.prv, pd.mod, pd.fun, pd.prb,
>  				      upp);
> -		if (prp == NULL)
> +		if (uprp == NULL)
>  			goto fail;
>  	} else
> -		upp = prp->prv_data;
> +		upp = uprp->prv_data;
>  
>  	switch (psp->pps_type) {
>  	case DTPPT_RETURN:
> @@ -202,7 +227,7 @@ static dt_probe_t *create_underlying(dtrace_hdl_t *dtp,
>  	     */
>  	}
>  
> -	return prp;
> +	return uprp;
>  
>  fail:
>  	probe_destroy(dtp, upp);
> @@ -394,8 +419,8 @@ static void enable_usdt(dtrace_hdl_t *dtp, dt_probe_t *prp)
>  static int trampoline(dt_pcb_t *pcb, uint_t exitlbl)
>  {
>  	dt_irlist_t		*dlp = &pcb->pcb_ir;
> -	const dt_probe_t	*prp = pcb->pcb_probe;
> -	const dt_uprobe_t	*upp = prp->prv_data;
> +	const dt_probe_t	*uprp = pcb->pcb_probe;
> +	const dt_uprobe_t	*upp = uprp->prv_data;
>  	const list_probe_t	*pop;
>  	uint_t			lbl_exit = pcb->pcb_exitlbl;
>  
> @@ -508,8 +533,8 @@ copyout_val(dt_pcb_t *pcb, uint_t lbl, uint32_t val, int arg)
>  static int trampoline_is_enabled(dt_pcb_t *pcb, uint_t exitlbl)
>  {
>  	dt_irlist_t		*dlp = &pcb->pcb_ir;
> -	const dt_probe_t	*prp = pcb->pcb_probe;
> -	const dt_uprobe_t	*upp = prp->prv_data;
> +	const dt_probe_t	*uprp = pcb->pcb_probe;
> +	const dt_uprobe_t	*upp = uprp->prv_data;
>  	const list_probe_t	*pop;
>  	uint_t			lbl_assign = dt_irlist_label(dlp);
>  	uint_t			lbl_exit = pcb->pcb_exitlbl;
> @@ -636,9 +661,9 @@ out:
>  	return name;
>  }
>  
> -static int attach(dtrace_hdl_t *dtp, const dt_probe_t *prp, int bpf_fd)
> +static int attach(dtrace_hdl_t *dtp, const dt_probe_t *uprp, int bpf_fd)
>  {
> -	dt_uprobe_t	*upp = prp->prv_data;
> +	dt_uprobe_t	*upp = uprp->prv_data;
>  	tp_probe_t	*tpp = upp->tp;
>  	FILE		*f;
>  	char		*fn;
> @@ -733,9 +758,9 @@ out:
>   * probes that didn't get created.  If the removal fails for some reason we are
>   * out of luck - fortunately it is not harmful to the system as a whole.
>   */
> -static void detach(dtrace_hdl_t *dtp, const dt_probe_t *prp)
> +static void detach(dtrace_hdl_t *dtp, const dt_probe_t *uprp)
>  {
> -	dt_uprobe_t	*upp = prp->prv_data;
> +	dt_uprobe_t	*upp = uprp->prv_data;
>  	tp_probe_t	*tpp = upp->tp;
>  
>  	if (!dt_tp_has_info(tpp))
> -- 
> 2.18.4
> 
> 
> _______________________________________________
> DTrace-devel mailing list
> DTrace-devel@oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/dtrace-devel

  reply	other threads:[~2024-06-04 18:45 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-04 18:10 "proof of concept" for systemwide USDT eugene.loh
2024-06-04 18:11 ` [PATCH 01/14] Move comment closer to the code it describes eugene.loh
2024-06-04 18:21   ` [DTrace-devel] " Kris Van Hees
2024-06-04 18:11 ` [PATCH 02/14] Clean up prp/uprp variable names eugene.loh
2024-06-04 18:44   ` Kris Van Hees [this message]
2024-06-05 18:18     ` [DTrace-devel] " Eugene Loh
2024-06-04 18:11 ` [PATCH 03/14] Let USDT module names contain dots eugene.loh
2024-06-04 20:42   ` [DTrace-devel] " Kris Van Hees
2024-06-04 22:30     ` Eugene Loh
2024-06-07 18:48       ` Nick Alcock
2024-06-07 22:22         ` Eugene Loh
2024-06-04 18:11 ` [PATCH 04/14] Track uprobe provider descriptions eugene.loh
2024-06-04 21:10   ` [DTrace-devel] " Kris Van Hees
2024-06-07 21:40     ` Eugene Loh
2024-06-07 22:16       ` Kris Van Hees
2024-06-10 21:23         ` Eugene Loh
2024-06-10 21:31           ` Kris Van Hees
2024-06-04 18:11 ` [PATCH 05/14] Add a hook for a provider-specific "update" function eugene.loh
2024-06-04 21:38   ` [DTrace-devel] " Kris Van Hees
2024-06-10 22:14     ` Eugene Loh
2024-06-04 18:11 ` [PATCH 06/14] Add clauses to per-uprobe list eugene.loh
2024-06-04 18:11 ` [PATCH 07/14] Create the BPF uprobes map eugene.loh
2024-06-05  4:33   ` [DTrace-devel] " Kris Van Hees
2024-06-10 20:55     ` Eugene Loh
2024-06-04 18:11 ` [PATCH 08/14] Use uprobes map to call clauses conditionally eugene.loh
2024-06-04 18:11 ` [PATCH 09/14] Systemwide USDT WIP eugene.loh
2024-06-04 18:11 ` [PATCH 10/14] Fix the consumer's picture of the EPID eugene.loh
2024-06-04 18:11 ` [PATCH 11/14] Back out the previous patch eugene.loh
2024-06-04 18:11 ` [PATCH 12/14] Fix comments that hardwire DBUF_ offsets eugene.loh
2024-06-04 18:11 ` [PATCH 13/14] Clean up some comments eugene.loh
2024-06-04 18:11 ` [PATCH 14/14] Have the consumer get the PRID from the output buffer eugene.loh

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=Zl9gqz2tK+BdRRSf@oracle.com \
    --to=kris.van.hees@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=eugene.loh@oracle.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