On 02/05/2024 14:35, Arnaldo Carvalho de Melo wrote: > On Thu, May 02, 2024 at 12:49:26PM +0100, Alan Maguire wrote: >> On 01/05/2024 00:00, Daniel Xu wrote: >>> On Tue, Apr 30, 2024 at 03:48:06PM GMT, Arnaldo Carvalho de Melo wrote: >>>> On Mon, Apr 29, 2024 at 04:45:59PM -0600, Daniel Xu wrote: >>>> Also 'decl_tag_kfuncs' is not enabled when using --btf_features=default, >>>> right? as: > >>>> BTF_DEFAULT_FEATURE(decl_tag_kfuncs, btf_decl_tag_kfuncs, false), > >>>> And that false is .default_enabled=false. > >>> I think that `false` is for `initial_value`, isn't it? The macro sets >>> the `default_enabled` field. > >> yep it's the initial unset value. Specifying an option in --btf_features >> flips that value, so for initial-off values they are switched on, while > > So --btf_features=something may mean "don't use that feature"? That is > confusing, perhaps the '-something' come in handy? > No, in fact --btf_features tries to move away from the model of having a mix of enable and skip features. The reason we do things this way is we inherited a situation where some features that would begin as off if not specified (encode FLOAT) and some that would start off as on unless a skip option was specified (encode VAR). Prior to --btf_features, we accordingly had --enable-feature and --skip-feature flags for these. However with --btf_features, all features are positive; that is, if specified, we enable var, float etc; there are no "skip" features. Under the hood however, we preserve the prior "enable or skip" semantics; that's why some default values have initial values of false (an "enable" feature under the hood) and some have an initial value of true (a "skip" value under the hood. But none of that is exposed to the --btf_features user; if a feature is wanted, they just add it to the list. >> initial-on values are switched off. I _think_ the intent here is to tag >> kfuncs by default, so we can add tag_kfuncs to the set of options > > Probably, if they are present in the file being BTF encoded. > >> specified in pahole-flags for v1.26. We won't be using "default" there >> as we want to call out the flags explicitly. > > Sure. > > - Arnaldo >
