On Thu, 3 Jun 2010, Sergei Shtylyov wrote: > David Brownell wrote: > >>>> When #include'd alone, <linux/usb/gadget.h> > >> causes a lot of compilation errors > >>>> and warnings -- all because it relies on the > >> including code to bring in the > >>>> necessary #include's instead of doing this > >> itself. > > >>> That's normal, > > > Right ... > > Hardly. > > >> We have different definitions of > >> normality, it seems. To me, it's not normal when I have to > >> figure out what to #include in a driver every time just to > >> satisfy one of the #include's dependencies. > > > Look at documentation for syscalls and you > > will notice they give a list of #includes > > which are required. Ergo, "normal". > > Give me a list then; document it. > > WBR, Sergei > > PS: I really didn't expect such opposition to an obvious patch... My experience has been that .h header files should #include (either directly or indirectly) enough files to satisfy their own needs, although not necessarily the needs of the .c files that reference them. For example, if your .h file defines a structure one of whose members is a struct device, then your .h file should #include <linux/device.h>. But if your structure only contains a pointer to a struct device then this isn't necessary, i.e., the compiler will accept it even though a .c file using your .h might need to refer to a member of struct device. On the other hand, it's a pain to verify that you have done this. I guess the easiest way is to write a .c file whose first #include is the .h file you want to test. In practice, many of the more-heavily referenced .h files tend to get #included first in almost every source file (either directly or indirectly) so the issue hardly ever comes up. 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
