Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp3988763pxy; Tue, 4 May 2021 14:58:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzNDg4VyrrDICpTKvRWR7CDQFwBwD5R7EQXOxbryCtSULo78OUOpfieyoyj4jiJyun1JryZ X-Received: by 2002:a63:5b20:: with SMTP id p32mr3152694pgb.173.1620165495615; Tue, 04 May 2021 14:58:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620165495; cv=none; d=google.com; s=arc-20160816; b=Wqfjjv/XLGBfnajqOw3RBBZ+SPV5U10Ns8Gzrfd5epturmz59k9hD5VpLmLAdhNJQE TmZQHSJ8dt18r8RPsSinr+Tex0zB5SujIdJrqH3vrpY+5S9PvnU32XCwlXozrv1RuPDQ /6RXA310LdMnChESRsMu7ZwgZ0EUYX7J5MMTV5JddAy7ysVGLMa+E4fJuC+CalRO9897 rwjA9V9S8x+dXIMrda0VNSzZ5DUqZ7nlekLTmln4WHsIg+E3RCPyWWfPoMtC9KJIhl9U 2ZeMO3xg/vZszq+OX8EyvyTyAu0XHBW4OdOHFJ28wx44ZR+JbuCpwTUr1UlBMdLfOMp6 hMrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=IJ9f88kGFWGiaYzrO4Eoi5CQBCpzPKvyH5r5pgJAvsY=; b=upKt/QZ+NdM/vLu72i0I1GnNzu16bCJYTjuQFxlDe7AYFnzD+AZMx4mpVcmD/vKRvL Dk1whG3IDeCR6SQd7uLFqIOKb0Po/lL27bc7iBSkuE0E9dmTlsPRZJ1v/PmcFPlCpitI 9WELkzPElMrraTil/1vdZ8ACNUkif5INlYXNOBsQZBIYCTXftDCijP+L/lGSTZkIrLKa 1nrRnb7pQcVRP7VL/BdMsX6vVR0iDp3CelHBLYXbDhIwOdfE6i+cBYtmqQitQmTDtTSJ ex5l6UKcG/7EM+FBDH92yCzEVQuWNkCWsGgeioVjbI+i7DsMHs2+VlHk9AwJ8OHPR0zY Ly9Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e21si4627794pgk.412.2021.05.04.14.58.02; Tue, 04 May 2021 14:58:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231421AbhEDUSo (ORCPT + 99 others); Tue, 4 May 2021 16:18:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51832 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230301AbhEDUSn (ORCPT ); Tue, 4 May 2021 16:18:43 -0400 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 916D0C061574; Tue, 4 May 2021 13:17:48 -0700 (PDT) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2) (envelope-from ) id 1le1U4-004AHK-M9; Tue, 04 May 2021 22:17:32 +0200 Message-ID: <70868660127bd13dcc47e94108483ff15827378c.camel@sipsolutions.net> Subject: Re: [PATCH 2/2] kconfig: unify cc-option and as-option From: Johannes Berg To: Masahiro Yamada , linux-kbuild@vger.kernel.org Cc: Nick Desaulniers , Arvind Sankar , Andrew Morton , Brendan Higgins , Catalin Marinas , Changbin Du , Krzysztof Kozlowski , Mauro Carvalho Chehab , Randy Dunlap , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Date: Tue, 04 May 2021 22:17:30 +0200 In-Reply-To: <20200614144341.1077495-2-masahiroy@kernel.org> References: <20200614144341.1077495-1-masahiroy@kernel.org> <20200614144341.1077495-2-masahiroy@kernel.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-malware-bazaar: not-scanned Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, So... I realized it's been a while: On Sun, 2020-06-14 at 23:43 +0900, Masahiro Yamada wrote: > cc-option and as-option are almost the same; both pass the flag to > $(CC). The main difference is the cc-option stops before the assemble > stage (-S option) whereas as-option stops after it (-c option). > But, I had noticed for a while now that M= build for an out-of-tree driver were causing some trouble. Not really completely "out-of-tree" but rather backported (https://backports.wiki.kernel.org/). And then I finally narrowed it down to this commit, specifically this: >  # Return y if the compiler supports , n otherwise > -cc-option = $(success,$(CC) -Werror $(CLANG_FLAGS) $(1) -S -x c /dev/null -o /dev/null) > +cc-option = $(success,mkdir .tmp_$$$$; trap "rm -rf .tmp_$$$$" EXIT; $(CC) -Werror $(CLANG_FLAGS) $(1) -c -x c /dev/null -o .tmp_$$$$/tmp.o) What happens is that we're doing make -C /path/to/kernel M=/path/to/driver But /path/to/kernel may be the installed distro kernel headers, and thus not be writable to the user doing the driver compile. Obviously, the user may need to 'sudo' anyway to install the result, but if just test- compiling, or even as better practice to not run everything as root, this ".tmp_$$" dir cannot be created. IOW, this broke compiler option detection when KBUILD_EXTMOD=/M= is used. It seems this is still supported (documented in kbuild docs), so I'm kind of hoping it could be fixed? But OTOH, I really don't know how, perhaps just using "mktemp -d" here instead of the hardcoded temp dir? Thanks, johannes