Thank Matthew for correcting me
On Sun, Feb 13, 2022 at 12:09 PM Matthew Wilcox wrote:
>
> On Sun, Feb 13, 2022 at 11:19:09AM +0800, Zhouyi Zhou wrote:
> > I think the key to the problem lies in your attached console.log
> > (pasted below), at times 0.014987 and 0.015995, I see there are two
> >
On Sun, Feb 13, 2022 at 11:19:09AM +0800, Zhouyi Zhou wrote:
> I think the key to the problem lies in your attached console.log
> (pasted below), at times 0.014987 and 0.015995, I see there are two
> locks (cpu_hotplug_lock and jump_label_mutex) holded while
> kmem_cache_alloc calls
Dear Paul
I think the key to the problem lies in your attached console.log
(pasted below), at times 0.014987 and 0.015995, I see there are two
locks (cpu_hotplug_lock and jump_label_mutex) holded while
kmem_cache_alloc calls __might_resched (0.023356).
I guess PowerPC's map_patch_area should
From: Christophe Leroy
> Sent: 11 February 2022 10:25
>
> When building kernel with CONFIG_CC_OPTIMISE_FOR_SIZE, several
> copies of csum_sub() are generated, with the following code:
>
> 0170 :
>170: 7c 84 20 f8 not r4,r4
>174: 7c 63 20 14
From: Christophe Leroy
> Sent: 11 February 2022 08:48
>
> Today's implementation of csum_shift() leads to branching based on
> parity of 'offset'
>
> 02f8 :
>2f8: 70 a5 00 01 andi. r5,r5,1
>2fc: 41 a2 00 08 beq 304
>300:
Having all the new files in place, we now enable Rust support
in the build system, including `Kconfig` entries related to Rust,
the Rust configuration printer, the target definition files,
the version detection script and a few other bits.
In the future, we will likely want to generate the target
Rust support
This is the patch series (v4) to add support for Rust as a second
language to the Linux kernel.
If you are interested in following this effort, please join us in
the mailing list at:
rust-for-li...@vger.kernel.org
and take a look at the project itself at:
Hi John Paul,
On Sat, Feb 12, 2022 at 7:27 PM John Paul Adrian Glaubitz
wrote:
>
> Is there any particular reason why this list excludes MIPS*, i386, big-endian
> PowerPC and SPARC targets which are already supported by the Rust programming
> language?
The variations we have so far were
On Sat, Feb 12, 2022 at 5:19 PM Russell King (Oracle)
wrote:
>
> Right, so why made it dependent on CPU_32v6 || CPU_32v6K if ARMv7 is
> supported? What about CPU_32v7? What about CPU_32v7M?
>
> I think it would be saner to use the CPU_V6, CPU_V6K, CPU_V7 and maybe
> CPU_V7M here - even bettern to
Hi!
On Sat, Feb 12, 2022 at 02:03:42PM +0100, Miguel Ojeda wrote:
> +config RUST
> + bool "Rust support"
> + depends on RUST_IS_AVAILABLE
> + depends on ARM64 || CPU_32v6 || CPU_32v6K || (PPC64 &&
> CPU_LITTLE_ENDIAN) || X86_64 || RISCV
Is there any particular reason why this list
On Sat, Feb 12, 2022 at 04:47:33PM +0100, Miguel Ojeda wrote:
> Hi Russell,
>
> On Sat, Feb 12, 2022 at 3:17 PM Russell King (Oracle)
> wrote:
> >
> > Please don't use CPU_32v6* here.
> >
> > It probably makes more sense to add a symbol "HAVE_RUST" and have the
> > appropriate architecture
Hi Russell,
On Sat, Feb 12, 2022 at 3:17 PM Russell King (Oracle)
wrote:
>
> Please don't use CPU_32v6* here.
>
> It probably makes more sense to add a symbol "HAVE_RUST" and have the
> appropriate architecture Kconfig files select HAVE_RUST.
We can do it whatever way arch maintainers prefer,
On Sat, Feb 12, 2022 at 02:03:42PM +0100, Miguel Ojeda wrote:
> +config RUST
> + bool "Rust support"
> + depends on RUST_IS_AVAILABLE
> + depends on ARM64 || CPU_32v6 || CPU_32v6K || (PPC64 &&
> CPU_LITTLE_ENDIAN) || X86_64 || RISCV
Please don't use CPU_32v6* here.
It probably makes
Our skiroot_defconfig doesn't enable FTRACE, and so doesn't get
STACKTRACE enabled either. That leads to a build failure since commit
1614b2b11fab ("arch: Make ARCH_STACKWALK independent of STACKTRACE")
made stacktrace.c build even when STACKTRACE=n.
arch/powerpc/kernel/stacktrace.c: In
14 matches
Mail list logo
