All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>,
	Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>,
	Paolo Valente
	<paolo.valente-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	James Smart <james.smart-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
	Dick Kennedy
	<dick.kennedy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
	linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
Subject: Re: make the blkcg and blkcg structures private
Date: Fri, 22 Apr 2022 06:23:18 +0200	[thread overview]
Message-ID: <20220422042318.GA9977@lst.de> (raw)
In-Reply-To: <YmHQS1pyIglK+gfS-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>

On Thu, Apr 21, 2022 at 11:44:43AM -1000, Tejun Heo wrote:
> The patches look all good to me and I'm not against making things more
> private but can you elaborate on the rationale a bit more? By and large, we
> have never been shy about putting things in the headers if there's *any*
> (perceived) gain to be made from doing so, or even just as a way to pick the
> locations for different things - type defs go on header and so on. Most of
> the inlines and [un]likely's that we have are rather silly with modern
> compilers with global optimizations, so it does make sense to get tidier,
> but if that's the rationale, mentioning that in the commit message, even
> briefly, would be great - ie. it should explain the benefits of adding these
> few accessors to keep the definition private.

Mostly to help me understand the code :)  between all the moving to
and from the css struture it is a bit of a mess, and limiting the scope
that deals with the structures greatly helps with that.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Tejun Heo <tj@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
	Paolo Valente <paolo.valente@linaro.org>,
	James Smart <james.smart@broadcom.com>,
	Dick Kennedy <dick.kennedy@broadcom.com>,
	linux-block@vger.kernel.org, cgroups@vger.kernel.org,
	linux-nvme@lists.infradead.org, linux-mm@kvack.org
Subject: Re: make the blkcg and blkcg structures private
Date: Fri, 22 Apr 2022 06:23:18 +0200	[thread overview]
Message-ID: <20220422042318.GA9977@lst.de> (raw)
In-Reply-To: <YmHQS1pyIglK+gfS@slm.duckdns.org>

On Thu, Apr 21, 2022 at 11:44:43AM -1000, Tejun Heo wrote:
> The patches look all good to me and I'm not against making things more
> private but can you elaborate on the rationale a bit more? By and large, we
> have never been shy about putting things in the headers if there's *any*
> (perceived) gain to be made from doing so, or even just as a way to pick the
> locations for different things - type defs go on header and so on. Most of
> the inlines and [un]likely's that we have are rather silly with modern
> compilers with global optimizations, so it does make sense to get tidier,
> but if that's the rationale, mentioning that in the commit message, even
> briefly, would be great - ie. it should explain the benefits of adding these
> few accessors to keep the definition private.

Mostly to help me understand the code :)  between all the moving to
and from the css struture it is a bit of a mess, and limiting the scope
that deals with the structures greatly helps with that.

  parent reply	other threads:[~2022-04-22  4:23 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20  4:27 make the blkcg and blkcg structures private Christoph Hellwig
2022-04-20  4:27 ` [PATCH 03/15] nvme-fc: fold t fc_update_appid into fc_appid_store Christoph Hellwig
2022-04-20  4:27 ` [PATCH 04/15] blk-cgroup: move blkcg_{get,set}_fc_appid out of line Christoph Hellwig
2022-04-20  4:27 ` [PATCH 05/15] blk-cgroup: move blk_cgroup_congested out line Christoph Hellwig
2022-04-20  4:27 ` [PATCH 06/15] blk-cgroup: move blkcg_{pin,unpin}_online out of line Christoph Hellwig
2022-04-20  4:27 ` [PATCH 07/15] blk-cgroup: move struct blkcg to block/blk-cgroup.h Christoph Hellwig
2022-04-20  4:27 ` [PATCH 08/15] blktrace: cleanup the __trace_note_message interface Christoph Hellwig
2022-04-20  4:27 ` [PATCH 09/15] blk-cgroup: replace bio_blkcg with bio_blkcg_css Christoph Hellwig
2022-04-20  4:27 ` [PATCH 13/15] blk-cgroup: cleanup blk_cgroup_congested Christoph Hellwig
2022-04-20  4:27 ` [PATCH 14/15] blk-cgroup: cleanup blkcg_maybe_throttle_current Christoph Hellwig
     [not found] ` <20220420042723.1010598-1-hch-jcswGhMUV9g@public.gmane.org>
2022-04-20  4:27   ` [PATCH 01/15] blk-cgroup: remove __bio_blkcg Christoph Hellwig
2022-04-20  4:27     ` Christoph Hellwig
2022-04-21 21:21     ` Tejun Heo
2022-04-20  4:27   ` [PATCH 02/15] nvme-fc: don't support the appid attribute without CONFIG_BLK_CGROUP_FC_APPID Christoph Hellwig
2022-04-20  4:27     ` Christoph Hellwig
2022-04-20  4:27   ` [PATCH 10/15] blk-cgroup: remove pointless CONFIG_BLOCK ifdefs Christoph Hellwig
2022-04-20  4:27     ` Christoph Hellwig
2022-04-20  4:27   ` [PATCH 11/15] blk-cgroup: remove unneeded includes from <linux/blk-cgroup.h> Christoph Hellwig
2022-04-20  4:27     ` Christoph Hellwig
2022-04-20  4:27   ` [PATCH 12/15] blk-cgroup: move blkcg_css to blk-cgroup.c Christoph Hellwig
2022-04-20  4:27     ` Christoph Hellwig
2022-04-20  4:27   ` [PATCH 15/15] kthread: unexport kthread_blkcg Christoph Hellwig
2022-04-20  4:27     ` Christoph Hellwig
2022-04-21 21:44   ` make the blkcg and blkcg structures private Tejun Heo
2022-04-21 21:44     ` Tejun Heo
     [not found]     ` <YmHQS1pyIglK+gfS-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2022-04-22  4:23       ` Christoph Hellwig [this message]
2022-04-22  4:23         ` Christoph Hellwig
     [not found]         ` <20220422042318.GA9977-jcswGhMUV9g@public.gmane.org>
2022-04-22 15:42           ` Tejun Heo
2022-04-22 15:42             ` Tejun Heo
2022-05-02 16:46   ` Christoph Hellwig
2022-05-02 16:46     ` Christoph Hellwig
2022-05-02 20:06 ` Jens Axboe

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=20220422042318.GA9977@lst.de \
    --to=hch-jcswghmuv9g@public.gmane.org \
    --cc=axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=dick.kennedy-dY08KVG/lbpWk0Htik3J/w@public.gmane.org \
    --cc=james.smart-dY08KVG/lbpWk0Htik3J/w@public.gmane.org \
    --cc=linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=paolo.valente-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.