Re: [PATCH] sched/tracing: append prev_state to tp args instead

From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Delyan Kratunov <delyank@fb.com>,
	"valentin.schneider@arm.com" <valentin.schneider@arm.com>,
	"bigeasy@linutronix.de" <bigeasy@linutronix.de>,
	"dietmar.eggemann@arm.com" <dietmar.eggemann@arm.com>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"andrii@kernel.org" <andrii@kernel.org>,
	"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"mingo@kernel.org" <mingo@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"rdunlap@infradead.org" <rdunlap@infradead.org>,
	"Kenta.Tada@sony.com" <Kenta.Tada@sony.com>,
	"adharmap@quicinc.com" <adharmap@quicinc.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"bristot@redhat.com" <bristot@redhat.com>,
	"ebiederm@xmission.com" <ebiederm@xmission.com>,
	"ast@kernel.org" <ast@kernel.org>,
	"legion@kernel.org" <legion@kernel.org>,
	"ed.tsai@mediatek.com" <ed.tsai@mediatek.com>,
	"u.kleine-koenig@pengutronix.de" <u.kleine-koenig@pengutronix.de>,
	"juri.lelli@redhat.com" <juri.lelli@redhat.com>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH] sched/tracing: append prev_state to tp args instead
Date: Fri, 22 Apr 2022 09:54:39 -0700	[thread overview]
Message-ID: <CAEf4BzbnFBkdpHdwf3Uf_yQDt5Sn8NVkQNUts70EDVu8KmhsHw@mail.gmail.com> (raw)
In-Reply-To: <20220422115557.0dc5cd86@gandalf.local.home>

On Fri, Apr 22, 2022 at 8:56 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Fri, 22 Apr 2022 13:09:03 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
>
> > If bpf wants to ride on them, it needs to suffer the pain of doing so.
>
> And I constantly hear that BPF is not an ABI, and is not guaranteed to work
> from one kernel version to the next.

Right, and that's true in terms of expectations of BPF users. But it's
also true that in pracitce people's tools have to keep working across
multiple kernel versions and we've developed multiple technologies
(e.g., BPF CO-RE) and techniques to allow people to adapt to kernel
changes. See [0] and [1] for some of the tricks people do in real
production tools to accommodate kernel changes. Some kernel changes
are easier to accommodate, some are harder. This particular one,
though, is pretty complicated as no function or symbol got renamed, so
it's much more involved to detect changes like this. But ultimately
people will do that anyway.

But the ask here is, given it's not too late and it's trivial to avoid
this breakage in the first place by reordering function arguments, we
(BPF users) kindly ask to consider doing that. Hopefully this trivial
change isn't hampering kernel development in any way.

  [0] https://github.com/iovisor/bcc/pull/3917
  [1] https://github.com/iovisor/bcc/pull/3747

>
> -- Steve