From: sdf@google.com
To: bpf@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andriin@fb.com,
zhuyifei@google.com, maheshb@google.com
Subject: BPF program metadata
Date: Wed, 29 Jul 2020 09:27:51 -0700 [thread overview]
Message-ID: <20200729162751.GC184844@google.com> (raw)
As discussed in
https://docs.google.com/presentation/d/1A9Anx8JPHl_pK1aXy8hlxs3V5pkrKwHHtkPf_-HeYTc
during BPF office hours, we'd like to attach arbitrary auxiliary
metadata to the program, for example, the build timestamp or the commit
hash.
IIRC, the suggestion was to explore BTF and .BTF.ext section in
particular.
We've spent some time looking at the BTF encoding and BTF.ext section
and we don't see how we can put this data into .BTF.ext or even .BTF
without any kernel changes.
The reasoning (at least how we see it):
* .BTF.ext is just a container with func_info/line_info/relocation_info
and libbpf extracts the data form this section and passes it to
sys_bpf(BPF_PROG_LOAD); the important note is that it doesn't pass the
whole container to the kernel, but passes the data that's been
extracted from the appropriate sections
* .BTF can be used for metadata, but it looks like we'd have to add
another BTF_INFO_KIND() to make it a less messy (YiFei, feel free to
correct me)
So the question is: are we missing something? Is there some way to add
key=value metadata to BTF that doesn't involve a lot of kernel changes?
If the restrictions above are correct, should we go back to trying to
put this metadata into .data section (or maybe even the new .metadata
section)? The only missing piece of the puzzle in that case is the
ability to extend BPF_PROG_LOAD with a way to say 'hold this map
unconditionally'.
next reply other threads:[~2020-07-29 16:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-29 16:27 sdf [this message]
2020-08-04 19:42 ` BPF program metadata sdf
2020-08-05 22:44 ` Alexei Starovoitov
2020-08-05 23:10 ` sdf
2020-08-06 17:06 ` BPF office hours via google meet. Was: " Alexei Starovoitov
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=20200729162751.GC184844@google.com \
--to=sdf@google.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=maheshb@google.com \
--cc=zhuyifei@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.