Hi Jeremy, On Fri, Sep 13, 2019 at 09:13:00AM +0100, Jeremy Sowden wrote: > In a previous patch-series [0], I removed all netfilter headers from the > blacklist of headers which could not be compiled standalone. I did so > by fixing the specific compilation failures of the headers in the list, > usually by adding a preprocessor conditional to check whether a particu- > lar config option was enabled and disable some function definition or > struct member which depended on that option. While this was effective, > it was not wholly satisfactory since it left a scattering of seemingly > random ifdefs throughout the headers. > > 0 - > https://lore.kernel.org/netfilter-devel/20190813113657.gb4...@azazel.net/T/ > > The reason why these ad-hoc conditionals were necessary is that there > were inconsistencies in how existing checks were used to disable code > when particular options were turned off. For example, a header A.h > might define a struct S which was only available if a particular config > option C was enabled, but A.h might be included by header B.h, which > defined a struct T with a struct S member without checking for C. If > A.h and B.h were included in X.c, which was only compiled if C was > enabled, everything worked as expected; however, trying to compile B.h > standalone when C was disabled would result in a compilation failure. > > In the previous versions of this patch-series, I attempted to provide a > more comprehensive solution by identifying the config options relevant > to each header and adding the appropriate conditionals to it where they > do not already exist. However, based on feedback and looking at some > other examples, it became apparent that a better approach was to > endeavour to fix the inconsistencies that made the new config checks > necessary, with a view to removing as many of them as possible.
At quick glance, I like this patch series.
