[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180328133830.3d5d74d3@gandalf.local.home>
Date: Wed, 28 Mar 2018 13:38:30 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Alexei Starovoitov <ast@...com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
"David S. Miller" <davem@...emloft.net>,
Daniel Borkmann <daniel@...earbox.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
netdev <netdev@...r.kernel.org>,
kernel-team <kernel-team@...com>,
linux-api <linux-api@...r.kernel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [PATCH v7 bpf-next 06/10] tracepoint: compute num_args at build
time
On Wed, 28 Mar 2018 10:10:34 -0700
Alexei Starovoitov <ast@...com> wrote:
> > and have:
> >
> > u64 tp_offset = (u64)tp - (u64)_sdata;
> >
> > if (WARN_ON(tp_offset > UINT_MAX)
> > return -EINVAL;
> >
> > btp->tp_offset = (u32)tp_offset;
>
> above math has to be build time constant, so warn_on likely
> won't work.
Right, it would require a BUILD_BUG_ON.
> imo the whole thing is too fragile and obscure.
> I suggest to compress this 8 bytes * num_of_tracepoints later.
> Especially would be good to do it in one way for
> bpf_raw_event_map, ftrace and other places.
Fair enough. We can defer this shrinkage to another time. I only
suggested it here over your concern for the added bloat.
-- Steve
Powered by blists - more mailing lists