On Sat, Dec 17, 2022 at 5:44 AM David Gow wrote:
>
> This series adds support for building and running code in the Rust
> programming language under x86_64 UML kernels.
Thanks for all your work and support on getting KUnit/UML + Rust ready
(long before we landed in mainline!).
> This series is c
On Sat, Dec 17, 2022 at 5:45 AM David Gow wrote:
>
> diff --git a/Documentation/rust/arch-support.rst
> b/Documentation/rust/arch-support.rst
> index 6982b63775da..a526ca1c688b 100644
> --- a/Documentation/rust/arch-support.rst
> +++ b/Documentation/rust/arch-support.rst
> @@ -17,3 +17,5 @@ Archi
On Sat, Mar 18, 2023 at 5:16 AM David Gow wrote:
>
> Nevertheless, only disable SSE on clang setups, as that's a simple way
> of working around everyone's bugs.
Sounds good to me. If GCC >= 11 has fixed it, should we instead test
for GCC < 11, i.e. it could help catching future new regressions li
On Sun, Feb 26, 2023 at 5:28 PM dev wrote:
>
> The arch_support table was not sorted alphabetically.
> Sorts the table properly.
Applied to `rust-fixes`, thanks!
Cheers,
Miguel
___
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infrad
;rust: Refactor the build target to allow the use of
> builtin targets")
> Signed-off-by: David Gow
I guess this should go through UML, but please let me know otherwise
(I don't see it in next).
Tested-by: Miguel Ojeda
Reviewed-by: Miguel Ojeda
Should this have a
Cc: sta...@vger.kernel.org
too?
Thanks!
Cheers,
Miguel
On Tue, Sep 3, 2024 at 7:15 PM Jiaxun Yang wrote:
>
> +
Spurious line?
> +config HAVE_GENERATE_RUST_TARGET
> + bool
> + depends on HAVE_RUST
> + help
> + This symbol should be selected by an architecture if it
> + supports generating Rust target files with
> +
On Tue, Sep 3, 2024 at 7:15 PM Jiaxun Yang wrote:
>
> We have a union and a type both named after mips_instruction,
> rust bindgen is not happy with this kind of naming alias.
For this sort of thing, you may be able to add it to the block list at
`rust/bindgen_parameters`, so that you don't need
On Tue, Sep 3, 2024 at 7:15 PM Jiaxun Yang wrote:
>
> We don't use builtin target as there is no sutiable baremetal
> target for us that can cover all ISA variants supported by kernel.
Since we should try to go away from using `target.json`: what was not
possible to enable via e.g. `-Ctarget-feat
On Tue, Sep 3, 2024 at 7:14 PM Jiaxun Yang wrote:
>
> This series added MIPS arch support to rust for linux,
> hopefully MIPS is not too late to the party :-)
Definitely not late :)
> Sample rust module tested on R4000(el),mips32,mips32r2el,mips64,
> mips64r2el,mips64r6el.
That is great, thanks
On Tue, Sep 3, 2024 at 7:53 PM Jiaxun Yang wrote:
>
> Thanks for your review!
You're welcome!
> Triples defined for MIPS bare-metal target is surprisingly lacking, we do have
> little-endian 32-bit bare-metal target mipsel-unknown-none but big-endian and
> 64 bit variants are missing.
Hmm... So
On Tue, Sep 3, 2024 at 8:32 PM Jiaxun Yang wrote:
>
> Ahh thanks for the elaboration.
You're welcome!
> However, kernel supports many ISA variants that are not defined by any rust
> target
> triple, I'm not really sure if it's appropriate to define them all in
> upstream.
They need to be in u
On Wed, Sep 4, 2024 at 9:38 AM Jiaxun Yang wrote:
>
> Reported at:
> https://github.com/rust-embedded/wg/issues/792#issuecomment-2328133517
Thanks for the link! Added to our bullet point about the target spec
file in https://github.com/Rust-for-Linux/linux/issues/2.
Cheers,
Miguel
Gow
Signed-off-by: Miguel Ojeda
---
.gitignore | 5 +
.rustfmt.toml| 12 +
Makefile | 175 +++-
arch/Kconfig | 6 +
arch/arm/Kconfig
vsprintf: add new `%pA` format specifier
Miguel Ojeda (18):
kallsyms: support "big" kernel symbols
kallsyms: increase maximum kernel symbol length to 512
kunit: take `kunit_assert` as `const`
rust: add C helpers
rust: add `compiler_builtins` crate
rust: import upstream `alloc`
On Mon, May 23, 2022 at 8:45 PM Nick Desaulniers
wrote:
>
> I'm super not into having the rust optimization level differ from the
> C optimization level. This is just someone having too much fun
> wrapping every compiler flag in a kbuild option. Either folks wan't
I mean, `Makefile`s are not my
On Thu, May 26, 2022 at 12:25 AM Nick Desaulniers
wrote:
>
> Is there a reason to not just turn clippy on always? Might be nicer to
> start off with good practices by default. :^)
The idea crossed my mind too [1], but sadly Clippy disables some
optimizations and in general is not intended to be u
Hi Masahiro,
On Sat, Jul 16, 2022 at 10:23 AM Masahiro Yamada wrote:
>
> Is it intentional to print the successful message to stderr?
I think it makes sense to change it to `stdout`, given the message is
the main point of running `rustavailable` for normal users, and those
that just want the sta
Hi Conor,
On Sat, Jul 16, 2022 at 2:42 PM Conor Dooley wrote:
>
> Maybe I am just missing something blatantly obvious here, but trying
> to build rust support in -next fails for me. I am using ClangBuiltLinux
> clang version 15.0.0 5b0788fef86ed7008a11f6ee19b9d86d42b6fcfa and LLD
> 15.0.0. Is it
On Sat, Jul 16, 2022 at 3:51 PM wrote:
>
> Ah right, sorry for the noise so. I checked the ml but didn't see a
> report there.
No apologies needed -- thanks to you for the report, instead! :)
> Thanks Miguel, good to know! I'll just wait around for a new version.
> Just been trying to get my CI
rted issues, tested the project,
helped spread the word, joined discussions and contributed in
other ways!
Please see also the acknowledgements on the previous cover letters.
Boqun Feng (2):
kallsyms: use `sizeof` instead of hardcoded size
kallsyms: avoid hardcoding buffer siz
Gow
Co-developed-by: Tiago Lam
Signed-off-by: Tiago Lam
Co-developed-by: Björn Roy Baron
Signed-off-by: Björn Roy Baron
Co-developed-by: Martin Rodriguez Reboredo
Signed-off-by: Martin Rodriguez Reboredo
Signed-off-by: Miguel Ojeda
---
.gitignore | 6
Hi Willy,
On Tue, Aug 2, 2022 at 2:26 PM Matthew Wilcox wrote:
>
> None of this (afaict) has been discussed on linux-fsdevel. And I may
> have missed somethiing, but I don't see the fs module in this series
> of patches. Could linux-fsdevel be cc'd on the development of Rust
> support for files
On Tue, Aug 2, 2022 at 3:48 PM Christoph Hellwig wrote:
>
> handwaiving and pointing to git trees is not how Linux development
> works. Please make sure all the patches go to the relevant lists
> and maintainers first, and actually do have ACKs.
Which hand-waving? In fact, we were requested to d
On Tue, Aug 2, 2022 at 4:01 PM Matthew Wilcox wrote:
>
> No objections to any of this. I love the idea of being able to write
> filesystems in Rust. I just think it would go more smoothly if
> linux-fsdevel were involved more closely so people at least have the
> option of being able to follow d
On Tue, Aug 2, 2022 at 5:09 PM Miguel Ojeda
wrote:
>
> Yeah, patch 17, exactly (patch 11 is the `alloc` import). I have asked
> Konstantin privately about them.
The patches are showing up now in lore -- not sure if it was just a
delay (which would be consistent with the lack of b
Hi Arnd,
On Wed, Aug 17, 2022 at 4:40 PM Arnd Bergmann wrote:
>
> Hi Miguel,
>
> I tried enabling rust support in the gcc builds I provide at
> https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/arm64/12.1.0/
Thanks for giving it a go!
> to make this more accessible, but it appears t
On Wed, Aug 17, 2022 at 6:11 PM Björn Roy Baron
wrote:
>
> There is already a prototype of such a driver. It can be found at
> https://github.com/Rust-GCC/cargo-gccrs. Unlike what the name suggests it is
> not cargo specific. It consists of two binaries. The first calls cargo, but
> tells it to
On Wed, Aug 17, 2022 at 5:51 PM Arnd Bergmann wrote:
>
> Thanks for the explanation. My hope was that building the kernel
Don't mention it!
> would actually be easier here than building the more complicated
> rust user space.
Yeah, the kernel is complicated for them in different ways, so I
assu
On Tue, Mar 18, 2025 at 9:07 AM David Gow wrote:
>
> Is there anything holding this up for the upcoming merge window?
>
> Miguel: I'm assuming you'd rather take this (and possibly [1] as well)
> via Rust, but if it goes in via the uml tree, that'd be fine by me,
> too.
We try to get arch maintain
On Tue, Mar 18, 2025 at 11:14 AM Johannes Berg
wrote:
>
> The list is fine, but the patch wasn't even CC'ed there, so we don't
> have it in our patchwork:
> https://patchwork.ozlabs.org/project/linux-um/list/
Ah, right, David added it.
> I was just picking up um patches, but given that it was a
On Wed, Apr 9, 2025 at 8:16 AM FUJITA Tomonori
wrote:
>
> Align iounmap() signature with other architectures.
Most indeed have `volatile`, but nios2 and m68k don't -- Cc'ing them
just in case.
Cc'ing also the original authors of both sides too.
Thanks!
Cheers,
Miguel
On Sat, Apr 12, 2025 at 2:54 AM FUJITA Tomonori
wrote:
>
> Remove the `volatile` qualifier used with __iomem in helper functions
> in io.c. These helper functions are just wrappers around the
> corresponding accessors so they are unnecessary.
>
> This fixes the following UML build error with CONFI
On Sat, Apr 12, 2025 at 2:54 AM FUJITA Tomonori
wrote:
>
> Remove the `volatile` qualifier used with __iomem in helper functions
> in io.c. These helper functions are just wrappers around the
> corresponding accessors so they are unnecessary.
>
> This fixes the following UML build error with CONFI
On Tue, Apr 15, 2025 at 6:54 PM Arnd Bergmann wrote:
>
> Rihgt, I tried this last week when it came up first, removing the
> 'volatile' annotations in the asm-generic/io.h header and then
> all the ones that caused build regressions on arm/arm64/x86
> randconfig and allmodconfig builds. This patc
On Tue, Apr 15, 2025 at 9:14 PM Miguel Ojeda
wrote:
>
> Applied to `rust-fixes` -- thanks everyone!
>
> [ Reworded for relative paths. - Miguel ]
Also:
[ Arnd explains [1] that removing the qualifier is the way forward
(thanks!):
Rihgt, I tried this last week
35 matches
Mail list logo
