All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Righi <arighi@nvidia.com>
To: Tejun Heo <tj@kernel.org>
Cc: void@manifault.com, multics69@gmail.com,
	linux-kernel@vger.kernel.org, sched-ext@meta.com
Subject: Re: [PATCH 3/4] sched_ext: Move internal type and accessor definitions to ext_internal.h
Date: Wed, 3 Sep 2025 22:52:33 +0200	[thread overview]
Message-ID: <aLiqkQPC09mq7sUu@gpd4> (raw)
In-Reply-To: <aLh0SAkBdIlGVLTU@slm.duckdns.org>

On Wed, Sep 03, 2025 at 07:00:56AM -1000, Tejun Heo wrote:
> Hello,
> 
> On Wed, Sep 03, 2025 at 12:32:29PM +0200, Andrea Righi wrote:
> > On Tue, Sep 02, 2025 at 01:48:05PM -1000, Tejun Heo wrote:
> > > There currently isn't a place to place SCX-internal types and accessors to
> > > be shared between ext.c and ext_idle.c. Create kernel/sched/ext_internal.h
> > > and move internal type and accessor definitions there. This trims ext.c a
> > > bit and makes future additions easier. Pure code reorganization. No
> > > functional changes.
> > 
> > Having sched_ext_ops and scx_*_flags defined in ext_internal.h feels a
> > bit counterintuitive, sched_ext_ops also includes the documentation for all
> > the scx callbacks. How about moving these to ext.h and everything else in
> > ext_internal.h?
> 
> Hmm... so, _internal headers are for things which aren't interesting to
> other subsystems in the kernel. ie. internal to this particular subsystem,
> which is the case here. I understand that _internal may be counter-intuitive
> if the reader isn't working in the kernel tree, but am not sure that's a
> primary concern in naming source files.

Yeah, that's probably fine. As for the documentation, it's easy to find it
anyway, so I think it's not an issue.

Everything else looks good to me, so for the whole patchset:

Acked-by: Andrea Righi <arighi@nvidia.com>

Thanks,
-Andrea

  reply	other threads:[~2025-09-03 20:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-02 23:48 [PATCHSET sched_ext/for-6.18] sched_ext: Misc changes Tejun Heo
2025-09-02 23:48 ` [PATCH 1/4] sched_ext: Make explicit scx_task_iter_relock() calls unnecessary Tejun Heo
2025-09-02 23:48 ` [PATCH 2/4] sched_ext: Keep bypass on between enable failure and scx_disable_workfn() Tejun Heo
2025-09-02 23:48 ` [PATCH 3/4] sched_ext: Move internal type and accessor definitions to ext_internal.h Tejun Heo
2025-09-03 10:32   ` Andrea Righi
2025-09-03 17:00     ` Tejun Heo
2025-09-03 20:52       ` Andrea Righi [this message]
2025-09-02 23:48 ` [PATCH 4/4] sched_ext: Put event_stats_cpu in struct scx_sched_pcpu Tejun Heo
2025-09-03 21:34 ` [PATCHSET sched_ext/for-6.18] sched_ext: Misc changes Tejun Heo

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=aLiqkQPC09mq7sUu@gpd4 \
    --to=arighi@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=multics69@gmail.com \
    --cc=sched-ext@meta.com \
    --cc=tj@kernel.org \
    --cc=void@manifault.com \
    /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.