From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 33D43208D7 for ; Tue, 20 Aug 2024 17:22:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724174575; cv=none; b=IwAmIMSz9TEWG6194TF0peeHCkORyBKszBKZdSVolb1sdSIG1OsZIXaG3kemS5ZZNJ/GfAxjZ6PlUnXOwErJG7RrI40K37NaYaAMaXG+bnxr5XlNN/3sWy90fYiIeiRa90bEr9bjWPujxvGb9qWHGOqjsVgq/KGQUf6JdG3TIOY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724174575; c=relaxed/simple; bh=Yk067SnRDTB/yWZvQw5AoltCb9lkUfMXeEMYixaFhDY=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=FEv8ciIJqOoG3noWWFLqeR47OeP8mz/j16OBe/HAjVWKAyidevOOk9Z+TsaazKnw85rTTqLZE6UW9RggwEESUK31EwwGr52b1ktKrz828fBUmQg9H2nhomAeHureF6w/EMcjce1fkViU7CjGT3NuzU108+k85OKBNjldmD+h3Os= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=R34Db0DX; arc=none smtp.client-ip=209.85.208.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="R34Db0DX" Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-5bec507f4ddso830a12.0 for ; Tue, 20 Aug 2024 10:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1724174572; x=1724779372; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=T/1WG/9ldCtAUxEKSi+2OpNUvCL9Q6L1YzxrQLiosWY=; b=R34Db0DXoE9il9XPwMR4eGxEgnmtotI7Eycc8RfswYB1hERV/3o6A9ziFSM6UEyGmC kTwSHLUCfHtMHNjCX3TmRSOqOfp5Pf6akwc8Wn3rZZk2EwS8ccMbGmnDiTadTU1T48vA 74A3OgNo72Yw6lq28qaHKUc3lHE6VMGJrxDaLYXzKQ2EdfLr2V6pRuIDTuiPb5B70gwN ltv2lAj/Yn+0k7OJX5YWsxL2EHhh0F/D5d8jCjAfpCNJlSY8+B7dxN5R0TFMdqNtJeKG CiqXHzEv/a2lDqyEoNrjDH1ntftTaKZZk1yQNX8dUSxPZchvRyFTm8bsFcyK/jgphgfq ZWgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724174572; x=1724779372; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=T/1WG/9ldCtAUxEKSi+2OpNUvCL9Q6L1YzxrQLiosWY=; b=Q4ghi/WAi4HshugP6UqspetSYw08feakfnDTrN8poCcRgDxhRDFK3Z90dXNlIPILzk iRV0MqDcO6xwghTjTVj6fr26PzBtUN+1XqcDjNClgIbwbVHOAYv7i5nUAVi+QiW1Gwiu Y288+5L3tW17Q3i5cG6xYzTXdIWJlN6cfhVOiO/HLRZO078y1906y5cpy0m7JmB5DFbk O1/u8IUqx4QBosjBsz5aJVylH/DkbccCOxAnoYMaflJVp91n7nUSFonLNTr0iMy/ffhH oYh9ZeR7tN8aop9HmgD6EqfRZBJVnd9f+tiZ9c9K+2Sba7HwhcdCh/dja6DznNIq5Bcc 323A== X-Forwarded-Encrypted: i=1; AJvYcCV2ZIAEe7228L9VPnSHI1lMgL2wR3ken9/N/x5aMLLWX/wUu/o8waWQ6x/ByQZ87Uw48pPm3agtj5jrRCHliQ==@vger.kernel.org X-Gm-Message-State: AOJu0Ywl2nQQuZMZOfTGIfGaOJgkmdZgYIVBR7ZprpdoAIEABModOSFP quQjVKypGAy+r5zPKPDHPpjksClYYk7gf0M7i1lVxE+BZtXryLF3k7CCiXwTVANCMNSQAtSVR7y 78fu/fRfUY0b2CPVeS1NYVlkrmyw/65V23Kyo X-Google-Smtp-Source: AGHT+IHnzEjfKJoOP6zSpqnlVKYAp79gjJZtHxgxIKFwml3ILU+99PRFpoeiHBZGo2fYFeU5opRvNpd5SUSI7TMWSrI= X-Received: by 2002:a05:6402:35c4:b0:5be:9bb0:1189 with SMTP id 4fb4d7f45d1cf-5bf0be0c727mr163175a12.2.1724174572142; Tue, 20 Aug 2024 10:22:52 -0700 (PDT) Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240819213534.4080408-1-mmaurer@google.com> <20240819213534.4080408-2-mmaurer@google.com> In-Reply-To: From: Matthew Maurer Date: Tue, 20 Aug 2024 10:22:39 -0700 Message-ID: Subject: Re: [PATCH v3 1/4] kbuild: rust: Define probing macros for rustc To: Miguel Ojeda Cc: dvyukov@google.com, ojeda@kernel.org, andreyknvl@gmail.com, Masahiro Yamada , Alex Gaynor , Wedson Almeida Filho , Nathan Chancellor , aliceryhl@google.com, samitolvanen@google.com, kasan-dev@googlegroups.com, linux-mm@kvack.org, glider@google.com, ryabinin.a.a@gmail.com, Nicolas Schier , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Nick Desaulniers , Bill Wendling , Justin Stitt , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, llvm@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 20, 2024 at 7:20=E2=80=AFAM Miguel Ojeda wrote: > > I had some feedback on v2 -- was it missed? > > https://lore.kernel.org/rust-for-linux/CANiq72khUrha-a+59KYZgc63w-3P9= =3DDp_fs=3D+sgmV_A17q+PTA@mail.gmail.com/ Sorry, I did miss that in the refresh. To respond to a few points before I send up a replacement for this patch: >> >> 1. `rustc` support will soon be a minimum rather than a pinned version. > In the meantime, this happened, so we should update this sentence. Will update. >> 2. We already support multiple LLVMs linked into `rustc`, and these are > I guess you mean `rustc` is able to use multiple major versions of > LLVM -- or what do you mean by "multiple LLVMs linked"? I meant that the `rustc` consumed by the kernel build may use a wide range of different LLVMs, including unreleased ones. This means that which options are valid fundamentally needs to be probed - there's not necessarily a clean "LLVM version" for us to use. I'll rephrase. >> +# $(rustc-option,) >> +# Return y if the Rust compiler supports , n otherwise >> +# Calls to this should be guarded so that they are not evaluated if >> +# CONFIG_HAVE_RUST is not set. >Hmm... why `HAVE_RUST`? Should that be `RUST_IS_AVAILABLE`? Or what is t>he intention? Perhaps a comment would help here -- e.g. something >like the comment I used in the original approach [1]. Otherwise we >will forget... :) Yes, this should be RUST_IS_AVAILABLE, will update. >Also, I guess you wanted to relax the precondition as much as >possible, which is great, just to double check, do we expect a case >outside `RUST=3Dy`? I expect this to be potentially used for whether you're *allowed* to set `RUST=3Dy` - for example, if a particular sanitizer is enabled, you may need to probe whether Rust+LLVM supports that sanitizer before allowing RUST to be set to y. >> rustc-option =3D $(success,trap "rm -rf .tmp_$$" EXIT; mkdir .tmp_$$; $(= RUSTC) $(1) --crate-type=3Drlib /dev/null -o .tmp_$$/tmp.rlib) >I also had `out-dir` [1] since, if I remember correctly, `rustc` may >create temporary files in a potentially read-only location even in >this case. OK, I will add that. >> Also, should we do `-Dwarnings` here? I don't think so - I can't think of a case where we'd want to error on a warning from an empty crate (though that may be a failure of imagination.) Do you have an example of a warning we might trip that we'd want to make the build reject an option's availability? > > Thanks! > > Cheers, > Miguel