On Tue, Apr 20, 2021 at 07:56:18AM +0200, Greg Kroah-Hartman wrote:
> I would LOVE it if some "executives" would see the above presentations,
> because then they would maybe actually fund developers to fix bugs and
> maintain the kernel code, instead of only allowing them to add new
> features.
>
On Mon, Apr 19, 2021 at 05:24:33PM -0700, Nick Desaulniers wrote:
> On Fri, Apr 16, 2021 at 10:39 AM Willy Tarreau wrote:
> >
> > resources usage, I'm really not convinced at all it's suited for
> > low-level development. I understand the interest of the experiment
> > to help the language evolve
Hi Nick,
On Mon, Apr 19, 2021 at 05:24:33PM -0700, Nick Desaulniers wrote:
> I don't think the introduction of Rust made Firefox _more_ insecure.
> https://wiki.mozilla.org/Oxidation#Within_Firefox
Browsers are human interfaces and do not fundamentally require low
level access to memory/hardware/
On Fri, Apr 16, 2021 at 10:39 AM Willy Tarreau wrote:
>
> resources usage, I'm really not convinced at all it's suited for
> low-level development. I understand the interest of the experiment
> to help the language evolve into that direction, but I fear that
> the kernel will soon be as bloated an
Hi Nick,
On Mon, Apr 19, 2021 at 10:36 PM Nick Desaulniers
wrote:
>
> This is a much different process than drafts thrown over the wall.
> What hope do any kernel contributors have to participate in the ISO
> WGs, other than hoping their contributions to a draft foresee/address
> any concerns mem
On Mon, Apr 19, 2021 at 01:35:56PM -0700, Nick Desaulniers wrote:
> On Fri, Apr 16, 2021 at 11:47 AM Paul E. McKenney wrote:
> >
> > On Thu, Apr 15, 2021 at 11:04:37PM -0700, Nick Desaulniers wrote:
> > > On Thu, Apr 15, 2021 at 9:27 PM Boqun Feng wrote:
> > > >
> > > > But I think the Rust Commu
On Fri, Apr 16, 2021 at 11:47 AM Paul E. McKenney wrote:
>
> On Thu, Apr 15, 2021 at 11:04:37PM -0700, Nick Desaulniers wrote:
> > On Thu, Apr 15, 2021 at 9:27 PM Boqun Feng wrote:
> > >
> > > But I think the Rust Community still wants to have a good memory model,
> > > and they are open to any k
On Mon, Apr 19, 2021 at 11:38 AM Paolo Bonzini wrote:
>
> It changes it for the worse, in that access to fields that are shared
> across threads *must* either use atomic types
Well, we won't be using those broken types in the core kernel, so that
would all be entirely on the Rust side.
And I don
On 19/04/21 19:14, Linus Torvalds wrote:
On Mon, Apr 19, 2021 at 2:36 AM Peter Zijlstra wrote:
I also don't see how this is better than seq_cst.
But yes, not broken, but also very much not optimal.
I continue to feel like kernel people should just entirely ignore the
C++ memory ordering sta
On Mon, Apr 19, 2021 at 2:36 AM Peter Zijlstra wrote:
>
> I also don't see how this is better than seq_cst.
>
> But yes, not broken, but also very much not optimal.
I continue to feel like kernel people should just entirely ignore the
C++ memory ordering standard.
It's inferior to what we alread
On Mon, Apr 19, 2021 at 11:40:54AM +0200, Paolo Bonzini wrote:
> On 19/04/21 11:36, Peter Zijlstra wrote:
> > On Mon, Apr 19, 2021 at 11:02:12AM +0200, Paolo Bonzini wrote:
> > > > void writer(void)
> > > > {
> > > > atomic_store_explicit(&seq, seq+1, memory_order_relaxed);
> > > > atom
On 19/04/21 11:36, Peter Zijlstra wrote:
On Mon, Apr 19, 2021 at 11:02:12AM +0200, Paolo Bonzini wrote:
void writer(void)
{
atomic_store_explicit(&seq, seq+1, memory_order_relaxed);
atomic_thread_fence(memory_order_acquire);
This needs to be memory_order_release. The only change i
On Mon, Apr 19, 2021 at 11:02:12AM +0200, Paolo Bonzini wrote:
> > void writer(void)
> > {
> > atomic_store_explicit(&seq, seq+1, memory_order_relaxed);
> > atomic_thread_fence(memory_order_acquire);
>
> This needs to be memory_order_release. The only change in the resulting
> assembly
On 19/04/21 10:26, Peter Zijlstra wrote:
On Mon, Apr 19, 2021 at 09:53:06AM +0200, Paolo Bonzini wrote:
On 19/04/21 09:32, Peter Zijlstra wrote:
On Sat, Apr 17, 2021 at 04:51:58PM +0200, Paolo Bonzini wrote:
On 16/04/21 09:09, Peter Zijlstra wrote:
Well, the obvious example would be seqlocks.
On Mon, Apr 19, 2021 at 10:26:57AM +0200, Peter Zijlstra wrote:
> https://godbolt.org/z/85xoPxeE5
That wants _Atomic on the seq definition for clang.
> void writer(void)
> {
> atomic_store_explicit(&seq, seq+1, memory_order_relaxed);
> atomic_thread_fence(memory_order_acquire);
>
>
On Mon, Apr 19, 2021 at 09:53:06AM +0200, Paolo Bonzini wrote:
> On 19/04/21 09:32, Peter Zijlstra wrote:
> > On Sat, Apr 17, 2021 at 04:51:58PM +0200, Paolo Bonzini wrote:
> > > On 16/04/21 09:09, Peter Zijlstra wrote:
> > > > Well, the obvious example would be seqlocks. C11 can't do them
> > >
>
On 19/04/21 09:32, Peter Zijlstra wrote:
On Sat, Apr 17, 2021 at 04:51:58PM +0200, Paolo Bonzini wrote:
On 16/04/21 09:09, Peter Zijlstra wrote:
Well, the obvious example would be seqlocks. C11 can't do them
Sure it can. C11 requires annotating with (the equivalent of) READ_ONCE all
reads of
On Sat, Apr 17, 2021 at 04:51:58PM +0200, Paolo Bonzini wrote:
> On 16/04/21 09:09, Peter Zijlstra wrote:
> > Well, the obvious example would be seqlocks. C11 can't do them
>
> Sure it can. C11 requires annotating with (the equivalent of) READ_ONCE all
> reads of seqlock-protected fields, but the
On Sat, Apr 17, 2021 at 04:21:27PM +0200, Willy Tarreau wrote:
> Well, I can't express how much I hate abstractions because I constantly
> need to know what it's doing under the hood, and I spend my time reading
> the output asm code because I always want to confirm my assumptions about
> the compi
On Wed, Apr 14, 2021 at 09:09:53PM +0100, Matthew Wilcox wrote:
> By the way, I don't think that Rust necessarily has to conform to the
> current way that Linux works. If this prompted us to track the current
> context (inside spinlock, handling interrupt, performing writeback, etc)
> and do away
On Thu, Apr 15, 2021 at 2:41 AM wrote:
> Regarding compilers, we support Clang-built kernels as well as
> `LLVM=1` builds where possible (i.e. as long as supported by
> the ClangBuiltLinux project). We also maintain some configurations
> of GCC-built kernels working, but they are not intended to b
On Sat, Apr 17, 2021 at 4:21 PM Willy Tarreau wrote:
>
> Well, I can't express how much I hate abstractions because I constantly
> need to know what it's doing under the hood, and I spend my time reading
> the output asm code because I always want to confirm my assumptions about
> the compiler not
On 16/04/21 17:58, Theodore Ts'o wrote:
Another fairly common use case is a lockless, racy test of a
particular field, as an optimization before we take the lock before we
test it for realsies. In this particular case, we can't allocate
memory while holding a spinlock, so we check to see without
On 16/04/21 09:09, Peter Zijlstra wrote:
Well, the obvious example would be seqlocks. C11 can't do them
Sure it can. C11 requires annotating with (the equivalent of) READ_ONCE
all reads of seqlock-protected fields, but the memory model supports
seqlocks just fine.
Simlar thing for RCU; C1
On Sat, Apr 17, 2021 at 04:24:43PM +0200, Peter Zijlstra wrote:
> On Sat, Apr 17, 2021 at 01:46:23PM +0200, Willy Tarreau wrote:
> > For me the old trick of casting one side as long long still works:
> >
> > unsigned long long mul3264(unsigned int a, unsigned int b)
> > {
> > return (u
On Sat, Apr 17, 2021 at 01:46:23PM +0200, Willy Tarreau wrote:
> For me the old trick of casting one side as long long still works:
>
> unsigned long long mul3264(unsigned int a, unsigned int b)
> {
> return (unsigned long long)a * b;
> }
>
> i386:
> :
> 0: 8b 44 24
On Sat, Apr 17, 2021 at 02:53:10PM +0100, Wedson Almeida Filho wrote:
> > > Note that this is
> > > another area where Rust offers advantages: read-only guards (in C, if you
> > > take a
> > > read lock, nothing prevents you from making changes to fields you should
> > > only be
> > > allowed to
On Fri, Apr 16, 2021 at 06:14:44PM +0200, Willy Tarreau wrote:
> But will this remain syntactically readable/writable by mere humans ?
I would certainly hope so.
> > Note that this is
> > another area where Rust offers advantages: read-only guards (in C, if you
> > take a
> > read lock, nothing
From: Peter Zijlstra
> Sent: 17 April 2021 12:17
...
> > (i'd argue this is C being broken; promoting only as far as int, when
> > assigning to an unsigned long is Bad, but until/unless either GCC fixes
> > that or the language committee realises that being stuck in the 1970s
> > is Bad, people are
On Fri, Apr 16, 2021 at 04:03:07PM +0100, Matthew Wilcox wrote:
> Well, we could do that in C too.
>
> struct unlocked_inode {
> spinlock_t i_lock;
> };
>
> struct locked_inode {
> spinlock_t i_lock;
> unsigned short i_bytes;
> blkcnt_t i_blocks;
> };
>
> struct locked_in
On Sat, Apr 17, 2021 at 12:41:23PM +, David Laight wrote:
> Or the cases where the locks are released in the 'wrong' order.
> Typically for:
> lock(table)
> item = lookup(table, key)
> lock(item)
> unlock(table)
> ...
> unlock(item)
This is expressible in Ru
..
> The more you make it look like (Kernel) C, the easier it is for us C
> people to actually read. My eyes have been reading C for almost 30 years
> by now, they have a lexer built in the optical nerve; reading something
> that looks vaguely like C but is definitely not C is an utterly painful
>
From: Peter Zijlstra
> Sent: 16 April 2021 15:19
>
> On Fri, Apr 16, 2021 at 02:07:49PM +0100, Wedson Almeida Filho wrote:
> > On Fri, Apr 16, 2021 at 01:24:23PM +0200, Peter Zijlstra wrote:
>
> > > int perf_event_task_enable(void)
> > > {
> > > + DEFINE_MUTEX_GUARD(event_mutex, ¤t->perf_event_
On Sat, Apr 17, 2021 at 01:17:21PM +0200, Peter Zijlstra wrote:
> Well, I think the rules actually make sense, at the point in the syntax
> tree where + happens, we have 'unsigned char' and 'int', so at that
> point we promote to 'int'. Subsequently 'int' gets shifted and bad
> things happen.
That
On Fri, Apr 16, 2021 at 07:08:29PM +0100, Matthew Wilcox wrote:
> On Fri, Apr 16, 2021 at 07:18:48PM +0200, Peter Zijlstra wrote:
> > On Fri, Apr 16, 2021 at 07:10:17PM +0200, Miguel Ojeda wrote:
> >
> > > Of course, UB is only a subset of errors, but it is a major one, and
> > > particularly crit
On Fri, Apr 16, 2021 at 4:24 AM Peter Zijlstra wrote:
> Simlar thing for RCU; C11 can't optimally do that; it needs to make
> rcu_dereference() a load-acquire [something ARM64 has already done in C
> because the compiler might be too clever by half when doing LTO :-(].
> But it's the compiler need
On Fri, Apr 16, 2021 at 12:27:39PM +0800, Boqun Feng wrote:
> Josh, I think it's good if we can connect to the people working on Rust
> memoryg model, I think the right person is Ralf Jung and the right place
> is https://github.com/rust-lang/unsafe-code-guidelines, but you
> cerntainly know better
On Thu, Apr 15, 2021 at 11:04:37PM -0700, Nick Desaulniers wrote:
> On Thu, Apr 15, 2021 at 9:27 PM Boqun Feng wrote:
> >
> > [Copy LKMM people, Josh, Nick and Wedson]
> >
> > On Thu, Apr 15, 2021 at 08:58:16PM +0200, Peter Zijlstra wrote:
> > > On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kern
On Fri, Apr 16, 2021 at 07:18:48PM +0200, Peter Zijlstra wrote:
> On Fri, Apr 16, 2021 at 07:10:17PM +0200, Miguel Ojeda wrote:
>
> > Of course, UB is only a subset of errors, but it is a major one, and
> > particularly critical for privileged code.
>
> I've seen relatively few UBSAN warnings tha
On 4/16/21 12:37 PM, Willy Tarreau wrote:
> Hi Miguel,
>
> On Fri, Apr 16, 2021 at 07:10:17PM +0200, Miguel Ojeda wrote:
>> And by having the compiler enforce this safe-unsafe split, you can
>> review safe code without having to constantly worry about UB; and be
>> extra alert when dealing with `u
Hi Miguel,
On Fri, Apr 16, 2021 at 07:10:17PM +0200, Miguel Ojeda wrote:
> And by having the compiler enforce this safe-unsafe split, you can
> review safe code without having to constantly worry about UB; and be
> extra alert when dealing with `unsafe` blocks.
I do appreciate this safe/unsafe sp
On Fri, Apr 16, 2021 at 07:10:17PM +0200, Miguel Ojeda wrote:
> Of course, UB is only a subset of errors, but it is a major one, and
> particularly critical for privileged code.
I've seen relatively few UBSAN warnings that weren't due to UBSAN being
broken.
On Fri, Apr 16, 2021 at 6:14 PM Willy Tarreau wrote:
>
> I'm really afraid by languages which force developers to do this or that.
> Many bugs in C come from casts because developers know their use case
> better than the compiler's developers, and result in lack of warnings
> when the code evolves
On Fri, Apr 16, 2021 at 5:43 PM Peter Zijlstra wrote:
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2659.htm
>
> That's just not making any damn sense what so ever. That seems to be
> about sprinkling abort() all over the place, which is just total
> rubbish.
No, it is not about that. It i
On Fri, Apr 16, 2021 at 11:58:05AM -0400, Theodore Ts'o wrote:
> Another fairly common use case is a lockless, racy test of a
> particular field, as an optimization before we take the lock before we
> test it for realsies. In this particular case, we can't allocate
> memory while holding a spinloc
On Fri, Apr 16, 2021 at 04:33:51PM +0100, Wedson Almeida Filho wrote:
> On Fri, Apr 16, 2021 at 04:19:07PM +0200, Peter Zijlstra wrote:
> > Does this also not prohibit constructs where modification must be done
> > while holding two locks, but reading can be done while holding either
> > lock?
>
>
On Fri, Apr 16, 2021 at 02:07:49PM +0100, Wedson Almeida Filho wrote:
> On Fri, Apr 16, 2021 at 01:24:23PM +0200, Peter Zijlstra wrote:
> > On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kernel.org wrote:
> > > - Featureful language: sum types, pattern matching, generics,
> > > RAII, lifetim
On Fri, Apr 16, 2021 at 05:04:41PM +0200, Miguel Ojeda wrote:
> Of course, we could propose something similar for C -- in fact, there
> was a recent discussion around this in the C committee triggered by my
> n2659 "Safety attributes for C" paper.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n
On Fri, Apr 16, 2021 at 04:19:07PM +0200, Peter Zijlstra wrote:
> Does this also not prohibit constructs where modification must be done
> while holding two locks, but reading can be done while holding either
> lock?
I don't believe it does. Remember that we have full control of the abstractions,
On Fri, Apr 16, 2021 at 4:19 PM Peter Zijlstra wrote:
>
> Does this also not prohibit constructs where modification must be done
> while holding two locks, but reading can be done while holding either
> lock?
Yeah, this came up in some discussions we had. There are some locking
patterns that we n
On Fri, Apr 16, 2021 at 02:07:49PM +0100, Wedson Almeida Filho wrote:
> There is nothing in C forcing developers to actually use DEFINE_MUTEX_GUARD.
> So
> someone may simply forget (or not know that they need) to lock
> current->perf_event_mutex and directly access some field protected by it. Thi
On Fri, Apr 16, 2021 at 1:24 PM Peter Zijlstra wrote:
>
> IMO RAII is over-valued, but just in case you care, the below seems to
> work just fine. No fancy new language needed, works today. Similarly you
> can create refcount_t guards, or with a little more work full blown
> smart_ptr crud.
Pleas
On Fri, Apr 16, 2021 at 02:07:49PM +0100, Wedson Almeida Filho wrote:
> On Fri, Apr 16, 2021 at 01:24:23PM +0200, Peter Zijlstra wrote:
> > int perf_event_task_enable(void)
> > {
> > + DEFINE_MUTEX_GUARD(event_mutex, ¤t->perf_event_mutex);
>
> There is nothing in C forcing developers to actua
On Fri, Apr 16, 2021 at 01:24:23PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kernel.org wrote:
> > - Featureful language: sum types, pattern matching, generics,
> > RAII, lifetimes, shared & exclusive references, modules &
> > visibility, powerful hygi
On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kernel.org wrote:
> - Featureful language: sum types, pattern matching, generics,
> RAII, lifetimes, shared & exclusive references, modules &
> visibility, powerful hygienic and procedural macros...
IMO RAII is over-valued, but just in case
On Fri, Apr 16, 2021 at 10:16:05AM +0200, Michal Kubecek wrote:
> And I don't see how the two languages might coexist peacefully without
> rust toolchain being necessary for building any kernel useful in
> practice and anyone seriously involved in kernel development having to
> be proficient in bot
On Thu, Apr 15, 2021 at 08:58:16PM +0200, Peter Zijlstra wrote:
>
> This; can we mercilessly break the .rs bits when refactoring? What
> happens the moment we cannot boot x86_64 without Rust crap on?
>
> We can ignore this as a future problem, but I think it's only fair to
> discuss now. I really
On Fri, Apr 16, 2021 at 06:02:33AM +0100, Wedson Almeida Filho wrote:
> On Fri, Apr 16, 2021 at 04:25:34AM +, Al Viro wrote:
> > And as one of those freaks I can tell
> > you where exactly I would like you to go and what I would like you to do
> > with implicit suggestions to start a browser w
On Fri, Apr 16, 2021 at 03:22:16AM +0100, Wedson Almeida Filho wrote:
> On Thu, Apr 15, 2021 at 08:58:16PM +0200, Peter Zijlstra wrote:
> > On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kernel.org wrote:
> >
> > > Rust is a systems programming language that brings several key
> > > advantages ov
On Thu, Apr 15, 2021 at 9:27 PM Boqun Feng wrote:
>
> [Copy LKMM people, Josh, Nick and Wedson]
>
> On Thu, Apr 15, 2021 at 08:58:16PM +0200, Peter Zijlstra wrote:
> > On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kernel.org wrote:
> >
> > > Rust is a systems programming language that brings sev
On Fri, Apr 16, 2021 at 06:02:33 +0100, Wedson Almeida Filho wrote:
> On Fri, Apr 16, 2021 at 04:25:34AM +, Al Viro wrote:
>
>>> Are you stating [what you perceive as] a fact or just venting? If the
>>> former,
>>> would you mind enlightening us with some evidence?
>>
>> How about "not everyo
On Fri, Apr 16, 2021 at 04:25:34AM +, Al Viro wrote:
> > Are you stating [what you perceive as] a fact or just venting? If the
> > former,
> > would you mind enlightening us with some evidence?
>
> How about "not everyone uses a browser as a part of their workflow"?
The documentation is ava
[Copy LKMM people, Josh, Nick and Wedson]
On Thu, Apr 15, 2021 at 08:58:16PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kernel.org wrote:
>
> > Rust is a systems programming language that brings several key
> > advantages over C in the context of the Linux kern
On Fri, Apr 16, 2021 at 03:22:16AM +0100, Wedson Almeida Filho wrote:
> > HTML is not a valid documentation format. Heck, markdown itself is
> > barely readable.
>
> Are you stating [what you perceive as] a fact or just venting? If the former,
> would you mind enlightening us with some evidence?
On Thu, Apr 15, 2021 at 08:58:16PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kernel.org wrote:
>
> > Rust is a systems programming language that brings several key
> > advantages over C in the context of the Linux kernel:
> >
> > - No undefined behavior in t
On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kernel.org wrote:
> Rust is a systems programming language that brings several key
> advantages over C in the context of the Linux kernel:
>
> - No undefined behavior in the safe subset (when unsafe code is
> sound), including memory safety an
On Thu, Apr 15, 2021 at 08:26:21AM +, David Laight wrote:
> ...
> > Besides just FP, 128-bit, etc, I remain concerned about just basic
> > math operations. C has no way to describe the intent of integer
> > overflow, so the kernel was left with the only "predictable" result:
> > wrap around. Un
On Thu, Apr 15, 2021 at 3:38 AM Kees Cook wrote:
>
> Before anything else: yay! I'm really glad to see this RFC officially
> hit LKML. :)
Thanks! :)
> When originally learning Rust I was disappointed to see that (by default)
> Rust similarly ignores the overflow problem, but I'm glad to see the
On Thu, Apr 15, 2021 at 2:23 AM Nick Desaulniers
wrote:
>
> Looks like Wedson's writeup is now live. Nice job Wedson!
> https://security.googleblog.com/2021/04/rust-in-linux-kernel.html
+1 It is very nicely written and explains the semaphore samples
(included in the RFC) he wrote, with nice table
...
> Besides just FP, 128-bit, etc, I remain concerned about just basic
> math operations. C has no way to describe the intent of integer
> overflow, so the kernel was left with the only "predictable" result:
> wrap around. Unfortunately, this is wrong in most cases, and we're left
> with entire c
Before anything else: yay! I'm really glad to see this RFC officially
hit LKML. :)
On Wed, Apr 14, 2021 at 10:20:51PM +0200, Miguel Ojeda wrote:
> - On floating-point, 128-bit, etc.: the main issue is that the
> `core` library is a single big blob at the moment. I have already
> mentioned this t
On Wed, Apr 14, 2021 at 11:47 AM wrote:
>
> From: Miguel Ojeda
>
> Some of you have noticed the past few weeks and months that
> a serious attempt to bring a second language to the kernel was
> being forged. We are finally here, with an RFC that adds support
> for Rust to the Linux kernel.
>
> Th
From: Linus Torvalds
> Sent: 14 April 2021 21:22
>
> On Wed, Apr 14, 2021 at 1:10 PM Matthew Wilcox wrote:
> >
> > There's a philosophical point to be discussed here which you're skating
> > right over! Should rust-in-the-linux-kernel provide the same memory
> > allocation APIs as the rust-stand
On Wed, Apr 14, 2021 at 01:21:52PM -0700, Linus Torvalds wrote:
> On Wed, Apr 14, 2021 at 1:10 PM Matthew Wilcox wrote:
> >
> > There's a philosophical point to be discussed here which you're skating
> > right over! Should rust-in-the-linux-kernel provide the same memory
> > allocation APIs as th
On Wed, Apr 14, 2021 at 10:10 PM Matthew Wilcox wrote:
>
> On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kernel.org wrote:
> > - Manish Goregaokar implemented the fallible `Box`, `Arc`, and `Rc`
> > allocator APIs in Rust's `alloc` standard library for us.
>
> There's a philosophical point
On Wed, Apr 14, 2021 at 1:10 PM Matthew Wilcox wrote:
>
> There's a philosophical point to be discussed here which you're skating
> right over! Should rust-in-the-linux-kernel provide the same memory
> allocation APIs as the rust-standard-library, or should it provide a Rusty
> API to the standar
On Wed, Apr 14, 2021 at 9:45 PM Linus Torvalds
wrote:
>
> With the main point of Rust being safety, there is no way I will ever
> accept "panic dynamically" (whether due to out-of-memory or due to
> anything else - I also reacted to the "floating point use causes
> dynamic panics") as a feature in
On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kernel.org wrote:
> - Manish Goregaokar implemented the fallible `Box`, `Arc`, and `Rc`
> allocator APIs in Rust's `alloc` standard library for us.
There's a philosophical point to be discussed here which you're skating
right over! Should rust
On Wed, Apr 14, 2021 at 11:46 AM wrote:
>
> Some of you have noticed the past few weeks and months that
> a serious attempt to bring a second language to the kernel was
> being forged. We are finally here, with an RFC that adds support
> for Rust to the Linux kernel.
So I replied with my reaction
79 matches
Mail list logo
