Messages in this thread | | | Date | Fri, 24 Feb 2023 15:18:03 -0800 (PST) | Subject | Re: [RFC 0/2] RISC-V: enable rust | From | Palmer Dabbelt <> |
| |
On Fri, 24 Feb 2023 14:38:28 PST (-0800), miguel.ojeda.sandonis@gmail.com wrote: > On Fri, Feb 24, 2023 at 10:32 PM Palmer Dabbelt <palmer@dabbelt.com> wrote: >> >> I'm fine with it, but IIRC the Rust support for most targets was pulled >> out as they weren't deemed ready to go yet. If the Rust folks are OK > > So we trimmed the original series from v8 to v9 as much as possible in > order to upstream things piece by piece, get maintainers involved, and > so on; i.e. they were not trimmed because they were not ready.
OK, cool, that's way less scary.
> Having said that, for the architectures support in particular, what we > had is indeed a prototype: each architecture we added was able to > compile, boot into QEMU, load the sample Rust modules, pass a few > tests, and so on in our CI, using a couple kernel configs. But that is > just the basic support, and it does not mean it works for other kernel > configs, all hardware, all security features, and so on. > > So it depends on how you want to approach it, whether you are > interested in the basic support or not, etc. In any case, I would > recommend having an expert on the architecture take a look to > double-check things look sane, run some tests on real hardware, etc.
We generally take stuff pretty early in RISC-V land, for example we take a bunch of stuff that's just in the ISA but doesn't have any hardware yet. The good news is that we don't really have any of the complicated language-tied features in RISC-V land, so with any luck it's pretty straight-forward to flip on.
>> turning on RISC-V support then it's fine with me, but I think it's >> really more up to them at this point. >> >> So >> >> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> >> >> in case folks want to take it via some Rust-related tree, but I'm also >> fine taking it via the RISC-V tree if that's easier. > > Thanks Palmer! We are trying to get maintainers of the different > subsystems/archs/... involved so that they maintain the different Rust > bits we are upstreaming, so ideally it would go through the RISC-V > tree.
Works for me.
I've got a few other things in the pipeline for this merge window so this probably won't make it, but I'll dig in after that. We've got a bunch of Rust-types floating around Rivos as well, so with any luck someone else will have some time to poke around. Having a full cycle in linux-next is probably the right way to go for this sort of thing anyway, as it's likely to shake out some long-tail issues.
That'll also give us time to sort out the authorship issues, which we'd of course need to do before merging anything.
| |