From: Conor Dooley <conor@kernel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: "Conor Dooley" <conor.dooley@microchip.com>,
linux-riscv@lists.infradead.org,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Wedson Almeida Filho" <wedsonaf@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nick Desaulniers" <ndesaulniers@google.com>,
"Tom Rix" <trix@redhat.com>,
rust-for-linux@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH v1 0/2] RISC-V: enable rust
Date: Thu, 18 Jan 2024 15:49:21 +0000 [thread overview]
Message-ID: <20240118-implode-delirium-eefdd86e170e@spud> (raw)
In-Reply-To: <CANiq72mVKCOAuK4Qe+8AHmpkFwyJsVfx8AqB7ccGi3DYpSSWcw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]
On Wed, Jan 17, 2024 at 07:23:17PM +0100, Miguel Ojeda wrote:
> On Wed, Jan 17, 2024 at 12:31 PM Conor Dooley <conor@kernel.org> wrote:
> >
> > 6.6 came and went, and I have been busy dealing with the other
> > responsibilities I mentioned and have not had a chance to look here.
> > I rebased this today and things still work as they did when I submitted
> > this version, but things have gotten muddier on the LLVM side of things,
> > as more recent versions have added yet more extension support.
>
> Sounds fun :)
>
> > My inclination at this point is to engage in a bit of LARPing as an
> > ostrich, and sorta ignore these concerns initially. Specifically, I'd
> > like to drop the idea of having the gcc support, and restrict to LLVM=1.
>
> Yeah, if `LLVM=1` works, then I would suggest going ahead with that.
>
> (Now that `rustc_codegen_gcc` is here, we will move to that and forget
> about mixed compiler builds, but we still have to handle `bindgen`
> flags until we have an alternative for that)
The bit that worries me most is bindgen, and in particular detecting the
version of libclang used. I mentioned to Nathan or Nick about needing a
buildtime test for the version of LIBCLANG being used.
I'm less worried about this for LLVM=1 builds, since while I think it is
possible to provide a LIBCLANG path to the build system, I suspect that
for LLVM=1 builds it's almost always going to match the LLVM toolchain
in use.
> > When it comes to asymmetrical extension support between the C and Rust
> > toolchains, I'm think we deal with that as we do for the C toolchains,
> > sort issues out as-and-when they arrive rather than punt this again.
>
> Sounds good, thanks a lot!
I'll do another rebase and resend after the merge window closes I
suppose :)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: "Conor Dooley" <conor.dooley@microchip.com>,
linux-riscv@lists.infradead.org,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Wedson Almeida Filho" <wedsonaf@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nick Desaulniers" <ndesaulniers@google.com>,
"Tom Rix" <trix@redhat.com>,
rust-for-linux@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH v1 0/2] RISC-V: enable rust
Date: Thu, 18 Jan 2024 15:49:21 +0000 [thread overview]
Message-ID: <20240118-implode-delirium-eefdd86e170e@spud> (raw)
In-Reply-To: <CANiq72mVKCOAuK4Qe+8AHmpkFwyJsVfx8AqB7ccGi3DYpSSWcw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1809 bytes --]
On Wed, Jan 17, 2024 at 07:23:17PM +0100, Miguel Ojeda wrote:
> On Wed, Jan 17, 2024 at 12:31 PM Conor Dooley <conor@kernel.org> wrote:
> >
> > 6.6 came and went, and I have been busy dealing with the other
> > responsibilities I mentioned and have not had a chance to look here.
> > I rebased this today and things still work as they did when I submitted
> > this version, but things have gotten muddier on the LLVM side of things,
> > as more recent versions have added yet more extension support.
>
> Sounds fun :)
>
> > My inclination at this point is to engage in a bit of LARPing as an
> > ostrich, and sorta ignore these concerns initially. Specifically, I'd
> > like to drop the idea of having the gcc support, and restrict to LLVM=1.
>
> Yeah, if `LLVM=1` works, then I would suggest going ahead with that.
>
> (Now that `rustc_codegen_gcc` is here, we will move to that and forget
> about mixed compiler builds, but we still have to handle `bindgen`
> flags until we have an alternative for that)
The bit that worries me most is bindgen, and in particular detecting the
version of libclang used. I mentioned to Nathan or Nick about needing a
buildtime test for the version of LIBCLANG being used.
I'm less worried about this for LLVM=1 builds, since while I think it is
possible to provide a LIBCLANG path to the build system, I suspect that
for LLVM=1 builds it's almost always going to match the LLVM toolchain
in use.
> > When it comes to asymmetrical extension support between the C and Rust
> > toolchains, I'm think we deal with that as we do for the C toolchains,
> > sort issues out as-and-when they arrive rather than punt this again.
>
> Sounds good, thanks a lot!
I'll do another rebase and resend after the merge window closes I
suppose :)
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2024-01-18 15:49 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-07 10:24 [PATCH v1 0/2] RISC-V: enable rust Conor Dooley
2023-03-07 10:24 ` Conor Dooley
2023-03-07 10:24 ` [PATCH v1 1/2] scripts: generate_rust_target: enable building on RISC-V Conor Dooley
2023-03-07 10:24 ` Conor Dooley
2023-03-07 11:21 ` Miguel Ojeda
2023-03-07 11:21 ` Miguel Ojeda
2023-03-07 10:24 ` [PATCH v1 2/2] RISC-V: enable building 64-bit kernels with rust support Conor Dooley
2023-03-07 10:24 ` Conor Dooley
2023-03-07 10:56 ` Miguel Ojeda
2023-03-07 10:56 ` Miguel Ojeda
2023-03-07 11:01 ` Conor Dooley
2023-03-07 11:01 ` Conor Dooley
2023-03-07 11:56 ` Miguel Ojeda
2023-03-07 11:56 ` Miguel Ojeda
2023-03-07 12:51 ` Conor Dooley
2023-03-07 12:51 ` Conor Dooley
2023-03-07 11:07 ` [PATCH v1 0/2] RISC-V: enable rust Miguel Ojeda
2023-03-07 11:07 ` Miguel Ojeda
2023-03-30 8:23 ` Conor Dooley
2023-03-30 8:23 ` Conor Dooley
2023-03-30 9:11 ` Conor Dooley
2023-03-30 9:11 ` Conor Dooley
2023-04-03 16:35 ` Miguel Ojeda
2023-04-03 16:35 ` Miguel Ojeda
2023-04-03 17:14 ` Conor Dooley
2023-04-03 17:14 ` Conor Dooley
2023-04-05 21:18 ` Conor Dooley
2023-04-05 21:18 ` Conor Dooley
2023-04-03 16:32 ` Miguel Ojeda
2023-04-03 16:32 ` Miguel Ojeda
2023-06-08 7:01 ` Conor Dooley
2023-06-08 7:01 ` Conor Dooley
2023-06-08 7:10 ` Conor Dooley
2023-06-08 7:10 ` Conor Dooley
2023-06-08 7:50 ` Kwanghoon Son
2023-06-08 7:50 ` Kwanghoon Son
2023-06-08 7:50 ` Kwanghoon Son
2023-06-08 11:52 ` Miguel Ojeda
2023-06-08 11:52 ` Miguel Ojeda
2023-06-08 12:28 ` Conor Dooley
2023-06-08 12:28 ` Conor Dooley
2024-01-17 11:30 ` Conor Dooley
2024-01-17 11:30 ` Conor Dooley
2024-01-17 18:23 ` Miguel Ojeda
2024-01-17 18:23 ` Miguel Ojeda
2024-01-18 15:49 ` Conor Dooley [this message]
2024-01-18 15:49 ` Conor Dooley
2024-01-18 16:09 ` Miguel Ojeda
2024-01-18 16:09 ` Miguel Ojeda
2024-01-25 12:30 ` Conor Dooley
2024-01-25 12:30 ` Conor Dooley
2024-01-25 12:50 ` Miguel Ojeda
2024-01-25 12:50 ` Miguel Ojeda
2024-01-25 13:45 ` Conor Dooley
2024-01-25 13:45 ` Conor Dooley
2024-01-26 21:00 ` Miguel Ojeda
2024-01-26 21:00 ` Miguel Ojeda
2024-01-26 22:00 ` Conor Dooley
2024-01-26 22:00 ` Conor Dooley
2024-01-27 13:46 ` Miguel Ojeda
2024-01-27 13:46 ` Miguel Ojeda
2024-02-09 15:18 ` Conor Dooley
2024-02-09 15:18 ` Conor Dooley
2024-02-10 8:13 ` Trevor Gross
2024-02-10 8:13 ` Trevor Gross
2024-02-12 19:03 ` Ramon de C Valle
2024-02-12 19:03 ` Ramon de C Valle
2024-02-12 20:36 ` Sami Tolvanen
2024-02-12 20:36 ` Sami Tolvanen
2024-02-13 20:08 ` Ramon de C Valle
2024-02-13 20:08 ` Ramon de C Valle
2024-02-14 3:14 ` Trevor Gross
2024-02-14 3:14 ` Trevor Gross
[not found] ` <CAOcBZORDaHHH3jTL3GO7OsDubhhyQE0Uy2uAjJpiRzrKBgqaOw@mail.gmail.com>
2024-02-12 19:11 ` Miguel Ojeda
2024-02-12 19:11 ` Miguel Ojeda
2024-02-12 20:17 ` Conor Dooley
2024-02-12 20:17 ` Conor Dooley
2024-02-12 20:37 ` Conor Dooley
2024-02-12 20:37 ` Conor Dooley
2024-02-13 20:09 ` Ramon de C Valle
2024-02-13 20:09 ` Ramon de C Valle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240118-implode-delirium-eefdd86e170e@spud \
--to=conor@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=conor.dooley@microchip.com \
--cc=corbet@lwn.net \
--cc=gary@garyguo.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=llvm@lists.linux.dev \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=ojeda@kernel.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=trix@redhat.com \
--cc=wedsonaf@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.