From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Qais Yousef <qais.yousef@arm.com>
Cc: peterz@infradead.org, vincent.donnefort@arm.com,
mingo@redhat.com, vincent.guittot@linaro.org,
linux-kernel@vger.kernel.org, valentin.schneider@arm.com,
Phil Auld <pauld@redhat.com>
Subject: Re: [PATCH v2] sched/debug: Add new tracepoint to track cpu_capacity
Date: Tue, 8 Sep 2020 18:17:54 +0200 [thread overview]
Message-ID: <d3fd557f-e38d-c4b4-1137-fcf0b06d3ba2@arm.com> (raw)
In-Reply-To: <20200908151722.b7ai2bpgvixlimz3@e107158-lin.cambridge.arm.com>
On 08/09/2020 17:17, Qais Yousef wrote:
> On 09/08/20 13:17, Dietmar Eggemann wrote:
>> On 07/09/2020 16:51, Qais Yousef wrote:
>>> On 09/07/20 13:13, peterz@infradead.org wrote:
>>>> On Mon, Sep 07, 2020 at 11:48:45AM +0100, Qais Yousef wrote:
>>>>> IMHO the above is a hack. Out-of-tree modules should rely on public headers and
>>>>> exported functions only. What you propose means that people who want to use
>>>>> these tracepoints in meaningful way must have a prebuilt kernel handy. Which is
>>>>> maybe true for us who work in the embedded world. But users who run normal
>>>>> distro kernels (desktop/servers) will fail to build against
>>>>
>>>> But this isn't really aimed at regular users. We're aiming this at
>>>> developers (IIUC) so I dont really see this as a problem.
>>
>> This is what I thought as well. All these helpers can be coded directly
>> in these tracepoint-2-traceevent (tp-2-te) converters. As long as they
>> are build from within kernel/sched/ there is no issue with the export
>> via kernel/sched/sched.h. Otherwise this little trick would be necessary.
>> But since it is a tool for developers I guess we can assume that they
>> can build it from within kernel/sched/.
>
> I think this will reduce the usefulness of these tracepoints. But if you really
> want to remove them, I am certainly not strongly attached to them and they were
> meant to be removable anyway. So fine by me :-)
I would like to see them go. Less stuff to maintain. And as we see with
the new cpu_capacity tp there are always more helper functions coming.
IMHO, the ability to build those modules via public headers is less
important since they are meant for developers.
next prev parent reply other threads:[~2020-09-08 17:18 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-28 9:00 vincent.donnefort
2020-08-28 10:27 ` Qais Yousef
2020-08-28 17:10 ` Dietmar Eggemann
2020-08-28 17:26 ` Qais Yousef
2020-09-02 10:44 ` Dietmar Eggemann
2020-09-02 13:54 ` Phil Auld
2020-09-07 11:02 ` Qais Yousef
2020-09-08 13:19 ` Phil Auld
2020-09-08 15:22 ` Qais Yousef
2021-01-04 18:26 ` Qais Yousef
2021-01-04 18:59 ` Alexei Starovoitov
2021-01-05 11:38 ` Qais Yousef
2021-01-05 16:44 ` Alexei Starovoitov
2021-01-06 11:27 ` Qais Yousef
2021-01-06 23:42 ` Andrii Nakryiko
2021-01-07 11:23 ` Qais Yousef
2021-01-11 14:04 ` Peter Zijlstra
2021-01-11 14:08 ` Qais Yousef
2020-09-07 10:48 ` Qais Yousef
2020-09-07 11:13 ` peterz
2020-09-07 14:51 ` Qais Yousef
2020-09-08 11:17 ` Dietmar Eggemann
2020-09-08 15:17 ` Qais Yousef
2020-09-08 16:17 ` Dietmar Eggemann [this message]
2021-01-04 15:18 ` Qais Yousef
2020-10-05 7:43 ` [tip: sched/core] " tip-bot2 for Vincent Donnefort
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=d3fd557f-e38d-c4b4-1137-fcf0b06d3ba2@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pauld@redhat.com \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=valentin.schneider@arm.com \
--cc=vincent.donnefort@arm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®