Re: make the blkcg and blkcg structures private

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

On Wed, Apr 20, 2022 at 06:27:08AM +0200, Christoph Hellwig wrote:
> this series cleans up various lose end in the blk-cgroup code to make it
> easier to follow in preparation of reworking the blkcg assignment for
> bios.  The biggest change is that most of <linux/blk-cgroup.h> is now
> taken private into block/.

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.

Thanks.

-- 
tejun




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux