From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2AD88C433EF for ; Tue, 29 Mar 2022 10:36:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235234AbiC2Khr (ORCPT ); Tue, 29 Mar 2022 06:37:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39726 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233793AbiC2Khn (ORCPT ); Tue, 29 Mar 2022 06:37:43 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C2022887B0; Tue, 29 Mar 2022 03:36:00 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5C96D6122F; Tue, 29 Mar 2022 10:36:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 638A2C340ED; Tue, 29 Mar 2022 10:35:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1648550159; bh=BpnVSnHL7Wyq0djkfiO8bZ3rjaX+b+Rn7WKaEVjMV/Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QoENHCGYpqfrb5U5Sq0SbyOcbWDNGjck+IdASRsHORmiZ5kQoE56vqddSMk3yn/9q Se5Ju7OO5CaE/eXH22eqPx0mSMN8KQjMB31mvQdPuqBcbSZWvHPmdiySCooUnvd24a e7CRc1uwSUszHIfhVMMa+pwq6Yp9yXez/krCSEjo= Date: Tue, 29 Mar 2022 12:35:56 +0200 From: Greg Kroah-Hartman To: Masahiro Yamada Cc: Linux Kbuild mailing list , Arnd Bergmann , Linux Kernel Mailing List , "Dmitry V. Levin" , Elliot Berman , Geert Uytterhoeven , Nick Desaulniers Subject: Re: [PATCH 2/2] kbuild: forbid exported headers from including , Message-ID: References: <20220328172130.197319-1-masahiroy@kernel.org> <20220328172130.197319-2-masahiroy@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > wrote: > > > > On Tue, Mar 29, 2022 at 02:21:30AM +0900, Masahiro Yamada wrote: > > > Some UAPI headers included , like this: > > > > > > #ifndef __KERNEL__ > > > #include > > > #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 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 , 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 . I put it as well before somebody > > > attempts to use it. > > > > > > Signed-off-by: Masahiro Yamada > > > > Nice work! > > > > Reviewed-by: Greg Kroah-Hartman > > > I made a mistake in the patch subject. > > The correct title should be: > > kbuild: forbid exported headers from including , > > I will fix it in v2. Ah, missed that, yes. > We cannot ban 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@google.com/ 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