On Mon, 5 Feb 2018, Linus Walleij wrote: > On Mon, Feb 5, 2018 at 10:27 AM, Julia Lawall <julia.lawall@xxxxxxx> wrote: > > On Mon, 5 Feb 2018, Linus Walleij wrote: > > >> We definitely need some better tooling to find these things, > >> using Ingo's head and your occasional frustration is not going to > >> scale. > >> > >> Julia: do you have ideas on tooling that can loosen #include > >> deps and advise on when to replace #includes with forward > >> declarations of structs (etc) to bring down rebuild-triggering > >> dependencies? > > > > Could you explain more? Is the point that you want to remove an include > > but it has one declaration that you need, and so you want to bring it down > > into the .c file? Would the need for that actually indicate that the > > include file is designed incorrectly? > > > > Can one assume that each include is self contained, ie it includes the > > things that it needs and does not rely on the .c file having included > > other things beforehand? > > Usually (in my limited experience, le's see what Ingo and Torvalds > say) the problem manifests mainly in include files including other > include files. > > So say <linux/foo.h>: > > #include <linux/bar.h> > > struct foo { > struct bar *barp; > }; > > Since this is only putting a pointer inside its struct and doesn't > need the information on the whole structs, as the size of a pointer > is well known we can reduce it to: > > struct bar; > > struct foo { > struct bar *barp; > }; > > And thus as <linux/bar.h> is not even included, it can change > all it wants, our foo.h include file is not affected, neither will > any driver just casually #including <linux/foo.h> need to be > rebuilt. > > This type of case (and variations on this theme) is the reason > we put a bunch of forward-declarations in kernel .h-files > just to break dependencies to stuff just referenced by pointer. > > There is a counter-pattern saying "files should #include the > headers prototypes, structs (etc) it uses" that drives a truck > through this approach. But IMO when done properly, this > forward-declaring approach is quite readable. > > I have very limited idea of where, whether in the preprocessor > or the compiler itself, the decision to treat struct bar *barp > as "just some pointer" happens, but it is a real neat trick, the > dependency chain is broken in CPP AFAICT anyways, and cuts > down the rebuilds. OK, thanks for the explanation. It seems like a very interesting problem. I will think about it and see if something can be done. It seems like it may need careful checking by a human, due to macros, ifdefs, etc, but perhaps it can at least be heplful to narrow down the opportunities. julia -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html