On Thu, 24 Jan 2013, Felipe Balbi wrote:
> > > +#include <uapi/linux/usb/ch9.h>
> >
> > Not needed; linux/usb/ch9.h already #includes it.
>
> wasn't it so that we shouldn't depend on indirect inclusion ?
I'm not quite sure what you mean. The uapi conversion pretty much
_had_ to do all those indirect inclusions. Otherwise it would have
been necessary to modify every source file that referenced one of the
files that got moved into a uapi subdirectory.
As regards the desirability of nested #includes...
Yes, there are diverging opinions on this matter. But practically
speaking, a few facts stand out:
The kernel is already full of indirect inclusions.
Many (probably nearly all) of the .c source files depend on
indirect inclusion to some extent.
Many of the .h files depend on feature defined in a different
.h file. This means that eliminating the nested inclusions
would impose dependencies among .h files; .c files would have
to #include them in the correct order.
Quite a few .h files demand that they _not_ be included
directly; they will generate an error if you try do so.
Avoiding indirect inclusion increases compile times and
increases the size of the kernel source tree.
Even if you wanted to #include directly every .h dependency
of your source file, you wouldn't be able to. There's no
practical way to determine whether you've left something
out that was #included indirectly by one of the other .h
files.
Given all these facts, I don't see much point in trying to avoid
indirect inclusion.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
