On Tue, Dec 02, 2025 at 11:21:47AM +0000, Coresight ML wrote:
On Tue, Dec 02, 2025 at 10:40:49AM +0000, James Clark wrote:
On 02/12/2025 10:15 am, Leo Yan wrote:
On Mon, Dec 01, 2025 at 04:41:04PM +0000, Coresight ML wrote:
[...]
+#define ADD_CONFIG_CHG(format_type, term_type, new_term) \ +{ \
- struct parse_events_term *term; \
- u64 bits = 0; \
- int type; \
\- list_for_each_entry(term, &head_config->terms, list) { \
if (term->type_term == PARSE_EVENTS__TERM_TYPE_USER) { \type = perf_pmu__format_type(pmu, term->config);\if (type != format_type) \continue; \bits |= perf_pmu__format_bits(pmu, term->config); \} else if (term->type_term == term_type) { \bits = ~(u64)0; \} \- } \
\- if (bits) \
ADD_CONFIG_TERM_VAL(new_term, cfg_chg, bits, false); \- return 0; \
Nitpick: "return 0" is not needed here. Otherwise:
Reviewed-by: Leo Yan leo.yan@arm.com
I think it's worse than not needed, it makes it stop collecting the changes after the first one.
Just curious how this can happen.
foo() { { chunk 1; }
{ chunk 2; }}
Seem to me, if without "return 0" in chunk 1, it still can continue to run chunk 2, no?
Please ignore my question above. We need to iterate from config to config4, if return 0 when handling config, then never add other configs?
Thanks, Leo