On Thu, 22 Mar 2018 08:51:16 -0700
Alexei Starovoitov wrote:
> So I definitely support the idea of build time warn for large
> number of args.
I'm more for a build time error for large number of args.
-- Steve
On 3/22/18 6:36 AM, Steven Rostedt wrote:
On Wed, 21 Mar 2018 15:05:46 -0700
Alexei Starovoitov wrote:
Like the only reason my patch is counting till 17 is because of
trace_iwlwifi_dev_ucode_error().
The next offenders are using 12 arguments:
trace_mc_event()
trace_mm_vmscan_lru_shrink_inactiv
On Wed, 21 Mar 2018 15:05:46 -0700
Alexei Starovoitov wrote:
> Like the only reason my patch is counting till 17 is because of
> trace_iwlwifi_dev_ucode_error().
> The next offenders are using 12 arguments:
> trace_mc_event()
> trace_mm_vmscan_lru_shrink_inactive()
>
> Clearly not every efficien
On 3/21/18 12:44 PM, Linus Torvalds wrote:
On Wed, Mar 21, 2018 at 11:54 AM, Alexei Starovoitov wrote:
add fancy macro to compute number of arguments passed into tracepoint
at compile time and store it as part of 'struct tracepoint'.
We should probably do this __COUNT() thing in some generic
On Wed, Mar 21, 2018 at 11:54 AM, Alexei Starovoitov wrote:
>
> add fancy macro to compute number of arguments passed into tracepoint
> at compile time and store it as part of 'struct tracepoint'.
We should probably do this __COUNT() thing in some generic header, we
just talked last week about an
From: Alexei Starovoitov
add fancy macro to compute number of arguments passed into tracepoint
at compile time and store it as part of 'struct tracepoint'.
The number is necessary to check safety of bpf program access that
is coming in subsequent patch.
for_each_tracepoint_range() api has no use
