From: Johannes Berg <johannes@sipsolutions.net>
To: "Zhao, Gang" <gamerh2o@gmail.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH 8/8] cfg80211: remove unnecessary include clauses
Date: Wed, 09 Apr 2014 14:36:59 +0200 [thread overview]
Message-ID: <1397047019.4964.8.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <87d2gqg05o.fsf@gmail.com> (sfid-20140409_142534_582747_BF7AE6C3)
On Wed, 2014-04-09 at 20:25 +0800, Zhao, Gang wrote:
> On Wed, 2014-04-09 at 09:49:30 +0200, Johannes Berg wrote:
> > I don't like those last four patches, I'd rather have more includes than
> > rely on other headers including headers that we need - that could change
> > after all.
>
> As I said in commit log, duplicate including could hide some warnings.
Well, the commit logs for these patches didn't have any such
information, but that's not really the point. Besides, what does "could
hide some warnings" even mean? This isn't a meaningful thing, if you
include the right headers then you should get what you need, and you
should include the headers for what you need.
> In theory, the possibility of change is equal, either it's a directly
> included header or a indirectly included header, and it's more likely to
> change to include more, not less. So the change may not cause any
> problem.
At the current point in time. If some of the headers that you rely on
including something no longer does in the future because it no longer
needs that, then you just broke everything. That's the point you
seemingly didn't consider, and I think it's much better to include what
you need rather than rely on somebody else doing it for you. The latter
can even be architecture-specific.
> In other way, the local directory header files may change more
> frequently than the header files in include/ directory. Whether it's a
> total win to apply the last four patches may be a question, but it's
> just amusing to see that lots of lines can be deleted. :-)
# of lines isn't a relevant metric though. If you were removing includes
that we didn't need that's certainly a useful thing, but removing
includes because they're indirectly already included is IMHO practically
always bad.
johannes
next prev parent reply other threads:[~2014-04-09 12:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-09 1:28 [PATCH 1/8] cfg80211: fix possible compile warning in wext-compat.h Zhao, Gang
2014-04-09 1:28 ` [PATCH 2/8] mac80211: fix possible compile warning in debugfs.h Zhao, Gang
2014-04-09 1:28 ` [PATCH 3/8] mac80211: fix possible compile warning in michael.h Zhao, Gang
2014-04-09 12:47 ` Johannes Berg
2014-04-09 1:28 ` [PATCH 4/8] mac80211: fix possible compile warning in debugfs_netdev.h Zhao, Gang
2014-04-09 12:50 ` Johannes Berg
2014-04-09 1:28 ` [PATCH 5/8] cfg80211: remove unnecessary include clauses (cfg80211.h) Zhao, Gang
2014-04-09 1:28 ` [PATCH 6/8] mac80211: remove unnecessary include clauses (mac80211.h) Zhao, Gang
2014-04-09 1:28 ` [PATCH 7/8] mac80211: remove unnecessary include clauses Zhao, Gang
2014-04-09 1:28 ` [PATCH 8/8] cfg80211: " Zhao, Gang
2014-04-09 7:49 ` Johannes Berg
2014-04-09 12:25 ` Zhao, Gang
2014-04-09 12:36 ` Johannes Berg [this message]
2014-04-09 12:43 ` Johannes Berg
2014-04-10 2:37 ` Zhao, Gang
2014-04-09 15:22 ` Zhao, Gang
2014-04-09 13:49 ` Zhao, Gang
2014-04-09 12:46 ` [PATCH 1/8] cfg80211: fix possible compile warning in wext-compat.h Johannes Berg
2014-04-09 14:18 ` Zhao, Gang
2014-04-10 8:02 ` Johannes Berg
2014-04-10 8:09 ` Johannes Berg
2014-04-11 0:27 ` Zhao, Gang
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=1397047019.4964.8.camel@jlt4.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=gamerh2o@gmail.com \
--cc=linux-wireless@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;
as well as URLs for NNTP newsgroup(s).