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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
