[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP4=nvQ69aK8NQno4X-WoHWF1yPPTiHwMOOKrzVGFoh-=oepRw@mail.gmail.com>
Date: Tue, 25 Nov 2025 14:35:50 +0100
From: Tomas Glozar <tglozar@...hat.com>
To: Wander Lairson Costa <wander@...hat.com>
Cc: Steven Rostedt <rostedt@...dmis.org>, LKML <linux-kernel@...r.kernel.org>,
Linux Trace Kernel <linux-trace-kernel@...r.kernel.org>, John Kacur <jkacur@...hat.com>,
Luis Goncalves <lgoncalv@...hat.com>, Costa Shulyupin <costa.shul@...hat.com>,
Crystal Wood <crwood@...hat.com>, Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: [PATCH v3 1/7] rtla/timerlat: Support tail call from BPF program
po 3. 11. 2025 v 15:24 odesÃlatel Wander Lairson Costa
<wander@...hat.com> napsal:
>> +/*
>> + * timerlat_bpf_set_action - set action on threshold executed on BPF side
>> + */
>> +static int timerlat_bpf_set_action(struct bpf_program *prog)
>> +{
>> + unsigned int key = 0, value = bpf_program__fd(prog);
>> +
>> + return bpf_map__update_elem(bpf->maps.bpf_action,
>> + &key, sizeof(key),
>> + &value, sizeof(value),
>> + BPF_ANY);
>> +}
>> +
>
> I believe it makes more sense to add the definition of this function to
> the patch where it is called.
>
Maybe, but I wrote this patch first, the rest of the patchset some
time after that. That is why it is this way; either way, it doesn't
hurt to define something before using it, the other way is worse.
Tomas
Powered by blists - more mailing lists