All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Qais Yousef <qais.yousef@arm.com>, Ingo Molnar <mingo@kernel.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Thara Gopinath <thara.gopinath@linaro.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched/core: Export pelt_thermal_tp
Date: Thu, 28 Oct 2021 18:50:46 +0200	[thread overview]
Message-ID: <YXrU5hQfEJFTP93d@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <YXrOLay3BbaDObM2@infradead.org>

On Thu, Oct 28, 2021 at 09:22:05AM -0700, Christoph Hellwig wrote:
> On Thu, Oct 28, 2021 at 06:18:55PM +0200, Peter Zijlstra wrote:
> > > > @@ -36,6 +36,7 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_rt_tp);
> > > >  EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_dl_tp);
> > > >  EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_irq_tp);
> > > >  EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_se_tp);
> > > > +EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_thermal_tp);
> > > >  EXPORT_TRACEPOINT_SYMBOL_GPL(sched_cpu_capacity_tp);
> > > >  EXPORT_TRACEPOINT_SYMBOL_GPL(sched_overutilized_tp);
> > > >  EXPORT_TRACEPOINT_SYMBOL_GPL(sched_util_est_cfs_tp);
> > > 
> > > ... and while we're at it, all these exports are unused and should
> > > be deleted as well.
> > 
> > This is my concession wrt tracepoints. Actual tracepoints are ABI,
> > exports are in-kernel interfaces and are explicitly not ABI.
> > 
> > This way people can use an external module to get at the tracepoint data
> > without having in-tree tracepoints.
> 
> All of this makes no sense at all.  These are entirely dead exports.
> If you remove them nothing else changes.  Note taht the tracepoints
> do have in-kernel callers, so if people thing of them as an ABI you've
> got your ABI already with or without the exports.

These are not normal traceevents, these are tracepoints, the distinction
is that these things do not show up in tracefs and there is no userspace
visible representation of them. No userspace gives no ABI.

All they provide is the in-code hook and in-kernel registration
interface. These EXPORTS export that registration interface, such that
an out-of-tree module can make use of them.

And yes, unused exports are iffy, out-of-tree modules are iffy, but in
this case I made an exception since ABI contraints are worse. We very
clearly state there is no such thing is kabi, so breaking any user of
these exports if fair game.

Breaking users of userspace trace-events gets kernel patches reverted
(been there, done that, never want to ever be there again).

People want to trace this stuff, but I *REALLY* do not want to commit to
ABI, this is the middle-ground that sucks least :/

  parent reply	other threads:[~2021-10-28 16:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-28 11:50 [PATCH] sched/core: Export pelt_thermal_tp Qais Yousef
2021-10-28 16:00 ` Christoph Hellwig
2021-10-28 16:18   ` Peter Zijlstra
2021-10-28 16:22     ` Christoph Hellwig
2021-10-28 16:48       ` Phil Auld
2021-10-28 16:50       ` Peter Zijlstra [this message]
2021-11-25 16:56         ` Qais Yousef
2022-01-28  7:40 ` [tip: sched/core] " tip-bot2 for Qais Yousef

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YXrU5hQfEJFTP93d@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=qais.yousef@arm.com \
    --cc=thara.gopinath@linaro.org \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.