[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72n-tMww2U+eQ=iHOh5u1JQgjM0b1E3XQ9jpWMfpdQ5+=g@mail.gmail.com>
Date: Tue, 23 Mar 2021 11:02:19 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Michael Ellerman <mpe@...erman.id.au>
Cc: rust-for-linux@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] Rust for Linux for ppc64le
Hi Michael,
On Tue, Mar 23, 2021 at 4:27 AM Michael Ellerman <mpe@...erman.id.au> wrote:
>
> Hi all,
>
> Here's a first attempt at getting the kernel Rust support building on powerpc.
Thanks a *lot*! It is great to have more architectures rolling.
> It's powerpc64le only for now, as that's what I can easily test given the
> distros I have installed. Though powerpc and powerpc64 are also Tier 2 platforms
Even if it is just 64-bit, it is very good to have it!
> so in theory should work. Supporting those would require something more
> complicated than just pointing rustc at arch/$(ARCH)/rust/target.json.
Yeah, the arch/$(ARCH)/rust/target.json dance is a placeholder -- I
need to figure out how to do that more cleanly, likely generating them
on the fly.
> This is based on 832575d934a2 from the Rust-for-Linux tree. Anything newer gives
> me errors about symbol name lengths. I figured I'd send this anyway, as it seems
> like those errors are probably not powerpc specific.
Sure, feel free to send things even if they don't work completely.
I will take a look at the symbol name lengths -- I increased that
limit to 512 and added support for 2-byte lengths in the tables, but
perhaps something is missing. If I manage to make it work, I can add
ppc64le to our CI! :-)
> Michael Ellerman (4):
> rust: Export symbols in initialized data section
> rust: Add powerpc64 as a 64-bit target_arch in c_types.rs
> powerpc/rust: Add target.json for ppc64le
> rust: Enable for ppc64le
Regarding the development process: at least until the RFC we are
working with the usual GitHub PR workflow (for several reasons: having
a quick CI setup, getting new Rust developers on-board, having a list
of "issues", cross-reference with the Rust repo, etc.).
I can take patches from the list, of course, but since we are pre-RFC,
do you mind if they get rebased etc. through there?
Thanks again!
Cheers,
Miguel
Powered by blists - more mailing lists