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 CFD9EC4332F for ; Thu, 9 Nov 2023 07:52:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232778AbjKIHxB (ORCPT ); Thu, 9 Nov 2023 02:53:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232613AbjKIHxA (ORCPT ); Thu, 9 Nov 2023 02:53:00 -0500 X-Greylist: delayed 550 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Wed, 08 Nov 2023 23:52:58 PST Received: from codesynthesis.com (codesynthesis.com [188.40.148.39]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A4E571716; Wed, 8 Nov 2023 23:52:58 -0800 (PST) Received: from brak.codesynthesis.com (unknown [105.186.92.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by codesynthesis.com (Postfix) with ESMTPSA id 55E5160D9F; Thu, 9 Nov 2023 07:43:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codesynthesis.com; s=mail1; t=1699515826; bh=fJ48MnwSMLL/XzmjxNLHtBoWhFyXgj04jwsCFx/3Hfs=; h=Date:From:To:Subject:Message-ID:MIME-Version:From; b=RmY00MK5Rg1p2bfkJRAejhbFOLJapXmR89HNVZ3EBm/VjgibjKGCFeSK65GEm8Qp7 7f9j1Jtr+eZAWyildkdVI5FnoKpLEsSBiJNckuM1L++5FiDEp+8rt9YCYWbIgMRdMb Al9k9Cj8OS7NQDRJOB2rhzeJeoJzRGMuS+3W9CmV5AryyGeE5UKAAZzMU29UM7zbiY x3wl9ICeAVqEmQZ1e99N5pzif5p18N2hGqk3Jl0HgiK1XdfCetqii0PTPMRIOpqlwL utdtn5Fd16cdAlWb9XZbkyCF9VkdxC5FIx/HpCvzr3tTDJ7dpJDm1ijUjadcTb7BzS uboZ2QLZ4arkQ== Received: by brak.codesynthesis.com (Postfix, from userid 1000) id 2AE8B145E0D; Thu, 9 Nov 2023 09:43:44 +0200 (SAST) Date: Thu, 9 Nov 2023 09:43:44 +0200 From: Boris Kolpackov To: Matthew Maurer Cc: Masahiro Yamada , Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , linux-kbuild@vger.kernel.org, Boqun Feng , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org Subject: Re: [PATCH 2/3] kconfig: Add special rust_modules config option Message-ID: References: <20231108022651.645950-2-mmaurer@google.com> <20231108022651.645950-5-mmaurer@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231108022651.645950-5-mmaurer@google.com> Organization: Code Synthesis Precedence: bulk List-ID: X-Mailing-List: linux-kbuild@vger.kernel.org Matthew Maurer writes: > Adds support for the rust_modules kconfig type, which works similarly to > modules, but for restricting or allowing the use of modules which > directly depend on Rust. > > [...] > > +struct symbol *modules_rust_sym; > +static tristate modules_rust_val; > + > +bool sym_depends_rust(struct symbol *sym) > +{ > + static struct symbol *rust_sym; > + > + if (!rust_sym) > + rust_sym = sym_find("RUST"); > + return expr_depends_symbol(sym->dir_dep.expr, rust_sym, true); > +} > + Hm, this feels like a quick and dirty hack to me: will we be hardcoding a symbol for each language? I know there is little sympathy for other projects that use Kconfig, and whatever Linux needs, goes, but still, this feels like a step too far.