On Tue, Mar 29, 2022 at 04:16:02PM +0900, Masahiro Yamada wrote: > On Tue, Mar 29, 2022 at 3:04 PM Greg Kroah-Hartman > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, Mar 29, 2022 at 02:21:30AM +0900, Masahiro Yamada wrote: > > > Some UAPI headers included <stdlib.h>, like this: > > > > > > #ifndef __KERNEL__ > > > #include <stdlib.h> > > > #endif > > > > > > As it turned out, they just included it for no good reason. > > > > > > After some fixes, now I can compile-test UAPI headers > > > (CONFIG_UAPI_HEADER_TEST=y) without <stdlib.h> included. > > > > > > To avoid somebody getting it back again, this commit adds the dummy > > > header, usr/dummy-include/stdlib.h > > > > > > I added $(srctree)/usr/dummy-include to the header search paths. > > > Because it is searched before the system directories, if someone > > > tries to include <stdlib.h>, they will see the error message. > > > > > > While I am here, I also replaced $(objtree)/usr/include with $(obj), but > > > it is just a small refactoring. > > > > > > If we achieve the situation where none of system headers is included > > > from exported kernel headers (i.e. kernel headers become self-contained), > > > we might be able to add -nostdinc, but that is much far from where we > > > stand now. (see many no-header-test lines in usr/include/Makefile) > > > > > > As a realistic solution, you can forbid header inclusion individually by > > > putting a dummy header into usr/dummy-include/. > > > > > > Currently, no header include <stdbool.h>. I put it as well before somebody > > > attempts to use it. > > > > > > Signed-off-by: Masahiro Yamada <masahiroy@xxxxxxxxxx> > > > > Nice work! > > > > Reviewed-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > > I made a mistake in the patch subject. > > The correct title should be: > > kbuild: forbid exported headers from including <stdlib.h>, <stdbool.h> > > I will fix it in v2. Ah, missed that, yes. > We cannot ban <stdint.h> for now because there are still some users. > > A fix-up patch exists, but the fuse maintainer was opposed to it. > https://lore.kernel.org/lkml/20220318171405.2728855-1-cmllamas@xxxxxxxxxx/ It's not ok for one lone file to break the rules that all other uapi header files follow. I think that needs to be fixed, there is NOTHING special about that one subsystem to justify this. Uniformity is good, and should be followed, and I strongly think that change needs to be accepted. thanks, greg k-h
