From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Alan Stern <stern@rowland.harvard.edu>, josh@joshtriplett.org
Cc: Rashika Kheria <rashika.kheria@gmail.com>,
linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org
Subject: Re: [PATCH 3/7] drivers: usb: Include appropriate header file in hcd.h
Date: Thu, 19 Dec 2013 21:03:27 +0300 [thread overview]
Message-ID: <52B334EF.1090202@cogentembedded.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1312191142501.984-100000@iolanthe.rowland.org>
Hello.
On 12/19/2013 07:48 PM, Alan Stern wrote:
>>> Of course, people have varying opinions on this issue. As far as I
>>> know, there is no fixed policy in the kernel about nested includes.
>> True. I personally prefer the policy of making all headers
>> self-contained, and then only including headers that define things used
>> in the source file. That has the advantage of not including any
>> unnecessary headers if the dependencies shrink, and not requiring
>> changes to multiple source files if the dependencies grow.
>> Any particular objection to making the headers self-contained?
> I guess it depends on what you mean by "self-contained". The only
> reasonable definition I can think of at the moment is that you don't
> get any errors or warnings when you compile the .h file by itself.
> But what use is that in practice? Nobody ever compiles .h files by
> themselves.
It's enough to verify that a .c file containing the given .h file would
not cause errors *located in that .h file*. This is not really such an
improbable situation, e.g. at the early stages of development. I did discover
header fiel errors this way.
> For that matter, how can you tell that you are including only headers
> that define things used in the source file?
I still think that's a whole different issue.
> Remove each #include line,
> one at a time, and see if you then get an error? Do you do this after
> each change to the source file to make sure it remains true over time?
That's what #include cleanup patches are for. Somebody has to do them from
time to time when the #include's accumulate -- they tend to accumulate as
people often forget to remove no longer needed one while removing some feature
from the .c file.
> My point is that the C language design and compiler infrastructure make
> it virtually impossible to enforce any fixed policy.
I don't really see how C language design can justify header files that
once included, require each .c file to #include other headers ahead of them,
each time such header is used. In my opinion, it's just crazy.
> Alan Stern
WBR, Sergei
next prev parent reply other threads:[~2013-12-19 17:03 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-19 10:06 [PATCH 1/7] drivers: usb: Include appropriate header file in hcd.c Rashika Kheria
2013-12-19 10:07 ` [PATCH 2/7] drivers: usb: Include appropriate header file in configfs.c Rashika Kheria
2013-12-19 10:09 ` [PATCH 3/7] drivers: usb: Include appropriate header file in hcd.h Rashika Kheria
2013-12-19 15:45 ` Alan Stern
2013-12-19 16:37 ` josh
2013-12-19 16:48 ` Alan Stern
2013-12-19 16:53 ` josh
2013-12-19 18:03 ` Sergei Shtylyov [this message]
2013-12-19 19:48 ` Alan Stern
2013-12-19 17:14 ` Sergei Shtylyov
2013-12-19 16:38 ` Alan Stern
2013-12-19 17:48 ` Sergei Shtylyov
2013-12-19 16:21 ` David Laight
2013-12-19 10:10 ` [PATCH 4/7] drivers: usb: Include appropriate header file in pci-quirks.c Rashika Kheria
2013-12-19 15:51 ` Alan Stern
2013-12-19 16:00 ` josh
2013-12-19 10:12 ` [PATCH 5/7] drivers: usb: Mark function as static in usbsevseg.c Rashika Kheria
2013-12-19 10:13 ` [PATCH 6/7] drivers: usb: Mark function as static in metro-usb.c Rashika Kheria
2013-12-19 10:14 ` [PATCH 7/7] drivers: usb: Include appropriate header file in phy-am335x-control.c Rashika Kheria
2013-12-19 16:36 ` [PATCH 1/7] drivers: usb: Include appropriate header file in hcd.c Greg Kroah-Hartman
2013-12-19 16:41 ` Rashika Kheria
2013-12-19 16:58 ` Greg Kroah-Hartman
2013-12-19 17:33 ` David Laight
2013-12-19 18:35 ` Josh Triplett
2013-12-20 9:40 ` David Laight
2013-12-19 18:34 ` Josh Triplett
2013-12-19 18:22 ` Greg Kroah-Hartman
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=52B334EF.1090202@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=gregkh@linuxfoundation.org \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rashika.kheria@gmail.com \
--cc=stern@rowland.harvard.edu \
/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.