Linux DTrace development list
 help / color / mirror / Atom feed
From: Nick Alcock <nick.alcock@oracle.com>
To: Kris Van Hees <kris.van.hees@oracle.com>
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH] bpf, btf: store BTF dict id for kernel modules
Date: Fri, 26 Apr 2024 12:37:48 +0100	[thread overview]
Message-ID: <871q6smk1f.fsf@esperi.org.uk> (raw)
In-Reply-To: <202404252045.43PKjFQ9020523@pps.reinject> (Kris Van Hees's message of "Thu, 25 Apr 2024 16:45:14 -0400")

On 25 Apr 2024, Kris Van Hees said:

> BPF requires a file descriptor (provided by the kernel) to be associated
> with BTF type ids for loadble kernel modules.  This file descriptor can

s/loadble/loadable/

> only be obtained from the kernel based on a BTF dict id for the module,
> and these ids are assigned dynamically at runtime when modules are
> loaded.

... were they *trying* to make this unnecessarily painful to use?

> Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>

Reviewed-by: Nick Alcock <nick.alcock@oracle.com>

with a few niggles

> diff --git a/libdtrace/dt_btf.h b/libdtrace/dt_btf.h
> index 0146386b..60256f12 100644
> --- a/libdtrace/dt_btf.h
> +++ b/libdtrace/dt_btf.h
> @@ -15,7 +15,8 @@
>  extern "C" {
>  #endif
>  
> -typedef struct dt_btf	dt_btf_t;
> +typedef struct dt_btf		dt_btf_t;
> +typedef struct bpf_btf_info	btf_info_t;

This sort of thing will start throwing compiler errors whenever any user
#includes the header that gives the concrete definition of any of those
types, because we're probably typedeffing them there too, and unlike
struct definitions you cannot repeat typedefs.

(Not a problem now, but just noting that this sort of pattern tends to
store up trouble for the future.)

> @@ -339,6 +340,8 @@ struct dtrace_hdl {
>  	char *dt_ctfa_path;	/* path to vmlinux.ctfa */
>  	ctf_archive_t *dt_ctfa; /* ctf archive for the entire kernel tree */
>  	struct dt_btf *dt_shared_btf; /* BTF data for the kernel (shared) */
> +	int dt_btf_cnt;		/* BTF id count */
> +	int *dt_btf_fds;	/* BTF id-to-fd mapping */
>  	ctf_file_t *dt_shared_ctf; /* Handle to the shared CTF */
>  	dt_htab_t *dt_kernpaths; /* hash table of dt_kern_path_t's */
>  	dt_module_t *dt_exec;	/* pointer to executable module */

These don't seem to be used anywhere in this patch: did you swap between
storing globally and storing per-module?

-- 
NULL && (void)

      reply	other threads:[~2024-04-26 11:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-25 20:45 [PATCH] bpf, btf: store BTF dict id for kernel modules Kris Van Hees
2024-04-26 11:37 ` Nick Alcock [this message]

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=871q6smk1f.fsf@esperi.org.uk \
    --to=nick.alcock@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=kris.van.hees@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