... > > > > > Long term plan here is to bring consistency to includes with benefits > > > > > of resilience and hopefully reducing just how much code is actually pulled > > > > > in whilst compiling. > > > > > > > > I forgot to mention that I've take a stricter view since doing this series > > > > so it needs an update even in the tree above. This mostly affects > > > > err.h, errno.h, stddef.h and types.h > > > > > > I don't think we need to include stddef.h to every C file, it should > > > be guaranteed via something like types.h or so. > > > > There are places with stddef.h but not types.h required. I debated which > > way to go on that and hence ended up with both for now, but it's obviously easy > > to tweak. Picking up on this particular example, I assumed it already would be included in something that was pretty much always present (such as types.h) but it isn't... So maybe I misinterpreted your comment and you are suggesting it would make sense to include stddef.h in types.h? Just looking at include/linux we have about 49 instances of stddef.h being included, 91 of types.h but only 16 of both... >From the few I looked at I suspect main reason it's needed is for the definition of NULL though lots of other headers are getting that indirectly. Naturally this is one of the mega list in kernel.h but at least there is no chance of a loop. I'm open to suggestions on how to proceed. Jonathan > > > > It may be that long term we look to have a standard kernel iwyu mapping file. > > It's possible to build in a fair bit of flexibility but maybe we'll need to > > tweak the tool to allow us even more. > > > > Jonathan > > > > > > > > > > > I'll update those in that tree sometime this week. > > > > > >
