From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Alan Maguire <alan.maguire@oracle.com>
Cc: Eduard Zingerman <eddyz87@gmail.com>,
andrii.nakryiko@gmail.com, jolsa@kernel.org, ast@kernel.org,
daniel@iogearbox.net, martin.lau@linux.dev, song@kernel.org,
yhs@fb.com, john.fastabend@gmail.com, kpsingh@kernel.org,
sdf@google.com, haoluo@google.com, mykolal@fb.com,
bpf@vger.kernel.org, Andrii Nakryiko <andrii@kernel.org>
Subject: Re: [RFC dwarves 3/4] pahole: add --btf_features=feature1[,feature2...] support
Date: Fri, 13 Oct 2023 11:17:34 -0300 [thread overview]
Message-ID: <ZSlRftMvOpscFe2S@kernel.org> (raw)
In-Reply-To: <401a9b36-9a4c-db0a-272c-e85eb31aeccd@oracle.com>
Em Thu, Oct 12, 2023 at 01:35:41PM +0100, Alan Maguire escreveu:
> On 11/10/2023 23:14, Eduard Zingerman wrote:
> > On Wed, 2023-10-11 at 23:05 +0100, Alan Maguire wrote:
> > [...]
> >>>>> I'm not sure I understand the logic behind "skip" features.
> >>>>> Take `decl_tag` for example:
> >>>>> - by default conf_load->skip_encoding_btf_decl_tag is 0;
> >>>>> - if `--btf_features=decl_tag` is passed it is still 0 because of the
> >>>>> `skip ? false : true` logic.
> >>>>>
> >>>>> If there is no way to change "skip" features why listing these at all?
> >>>>>
> >>>> You're right; in the case of a skip feature, I think we need the
> >>>> following behaviour
> >>>>
> >>>> 1. we skip the encoding by default (so the equivalent of
> >>>> --skip_encoding_btf_decl_tag, setting skip_encoding_btf_decl_tag
> >>>> to true
> >>>>
> >>>> 2. if the user however specifies the logical inversion of the skip
> >>>> feature in --btf_features (in this case "decl_tag" - or "all")
> >>>> skip_encoding_btf_decl_tag is set to false.
> >>>>
> >>>> So in my code we had 2 above but not 1. If both were in place I think
> >>>> we'd have the right set of behaviours. Does that sound right?
> >>>
> >>> You mean when --features=? is specified we default to
> >>> conf_load->skip_encoding_btf_decl_tag = true, and set it to false only
> >>> if "all" or "decl_tag" is listed in features, right?
> >>>
> >>
> >> Yep. Here's the comment I was thinking of adding for the next version,
> >> hopefully it clarifies this all a bit more than the original.
> >>
> >> +/* --btf_features=feature1[,feature2,..] allows us to specify
> >> + * a list of requested BTF features or "all" to enable all features.
> >> + * These are translated into the appropriate conf_load values via
> >> + * struct btf_feature which specifies the associated conf_load
> >> + * boolean field and whether its default (representing the feature being
> >> + * off) is false or true.
> >> + *
> >> + * btf_features is for opting _into_ features so for a case like
> >> + * conf_load->btf_gen_floats, the translation is simple; the presence
> >> + * of the "float" feature in --btf_features sets conf_load->btf_gen_floats
> >> + * to true.
> >> + *
> >> + * The more confusing case is for features that are enabled unless
> >> + * skipping them is specified; for example
> >> + * conf_load->skip_encoding_btf_type_tag. By default - to support
> >> + * the opt-in model of only enabling features the user asks for -
> >> + * conf_load->skip_encoding_btf_type_tag is set to true (meaning no
> >> + * type_tags) and it is only set to false if --btf_features contains
> >> + * the "type_tag" feature.
> >> + *
> >> + * So from the user perspective, all features specified via
> >> + * --btf_features are enabled, and if a feature is not specified,
> >> + * it is disabled.
> >> */
> >
> > Sounds reasonable. Maybe also add a line saying that
> > skip_encoding_btf_decl_tag defaults to false if --btf_features is not
> > specified to remain backwards compatible?
> >
>
> good idea, will do! Thanks!
I have to catch up with all the comments on this thread, but does this
mean you're respinning the series now?
- Arnaldo
next prev parent reply other threads:[~2023-10-13 14:17 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-11 9:17 [RFC dwarves 0/4] pahole, btf_encoder: support --btf_features Alan Maguire
2023-10-11 9:17 ` [RFC dwarves 1/4] btf_encoder, pahole: move btf encoding options into conf_load Alan Maguire
2023-10-12 12:54 ` Jiri Olsa
2023-10-11 9:17 ` [RFC dwarves 2/4] dwarves: move ARRAY_SIZE() to dwarves.h Alan Maguire
2023-10-11 9:17 ` [RFC dwarves 3/4] pahole: add --btf_features=feature1[,feature2...] support Alan Maguire
2023-10-11 16:28 ` Eduard Zingerman
2023-10-11 16:41 ` Alan Maguire
2023-10-11 19:08 ` Eduard Zingerman
2023-10-11 22:05 ` Alan Maguire
2023-10-11 22:14 ` Eduard Zingerman
2023-10-12 12:35 ` Alan Maguire
2023-10-13 14:17 ` Arnaldo Carvalho de Melo [this message]
2023-10-13 14:43 ` Alan Maguire
2023-10-12 12:53 ` Jiri Olsa
2023-10-12 13:48 ` Alan Maguire
2023-10-12 21:19 ` Jiri Olsa
2023-10-13 0:21 ` Andrii Nakryiko
2023-10-13 11:54 ` Alan Maguire
2023-10-13 18:39 ` Andrii Nakryiko
2023-10-11 9:17 ` [RFC dwarves 4/4] pahole: add --supported_btf_features to display feature support Alan Maguire
2023-10-13 0:14 ` [RFC dwarves 0/4] pahole, btf_encoder: support --btf_features Andrii Nakryiko
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=ZSlRftMvOpscFe2S@kernel.org \
--to=acme@kernel.org \
--cc=alan.maguire@oracle.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--cc=mykolal@fb.com \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=yhs@fb.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.