From: Christoph Hellwig <hch@infradead.org>
To: Caleb Sander Mateos <csander@purestorage.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
Anuj Gupta <anuj20.g@samsung.com>
Subject: Re: [PATCH v2] t10-pi: reduce ref tag code duplication
Date: Fri, 17 Apr 2026 00:56:55 -0700 [thread overview]
Message-ID: <aeHnx2GcBmutcsBW@infradead.org> (raw)
In-Reply-To: <CADUfDZpcNG_GPpZYh9tWKEBjKHD53DVCmQGTrXKQvBpP7PCqsg@mail.gmail.com>
On Thu, Apr 16, 2026 at 08:38:07AM -0700, Caleb Sander Mateos wrote:
> On Wed, Apr 15, 2026 at 10:18 PM Christoph Hellwig <hch@infradead.org> wrote:
> >
> > On Wed, Apr 15, 2026 at 03:08:47PM -0600, Caleb Sander Mateos wrote:
> > > #ifndef _LINUX_T10_PI_H
> > > #define _LINUX_T10_PI_H
> > >
> > > #include <linux/types.h>
> > > #include <linux/blk-mq.h>
> > > +#include <linux/wordpart.h>
> >
> > We must have already gotten this implicitly given that the code
> > already uses lower_48_bits.
>
> lower_48_bits() is defined (and only used) in this header. Yes,
> wordpart.h is already transitively included by the other headers, but
> I think it's good practice for each file to explicitly include the
> headers defining all the items it uses. It reduces the risk that
> refactoring the other header files in the future will result in a
> compilation error here by dropping the transitive include.
In general pulling in a new header when no new user of it shows up is a
bit weird. I don't want to hold the patch up on this, but there are
folks out there actually dropping not needed includes from headers as
it can significantly reduce compile time. Now this is not a heavily
included header so it's unlikely to make a difference anyway.
next prev parent reply other threads:[~2026-04-17 7:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 21:08 [PATCH v2] t10-pi: reduce ref tag code duplication Caleb Sander Mateos
2026-04-16 5:18 ` Christoph Hellwig
2026-04-16 15:38 ` Caleb Sander Mateos
2026-04-17 7:56 ` Christoph Hellwig [this message]
2026-04-17 15:34 ` Caleb Sander Mateos
2026-04-17 16:52 ` Keith Busch
2026-04-17 20:39 ` 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=aeHnx2GcBmutcsBW@infradead.org \
--to=hch@infradead.org \
--cc=anuj20.g@samsung.com \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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