linux-kernel - Re: On community influencing (was Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction.)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <C0508D03-FE8E-4253-A29D-97E7E3768CC4@gmail.com>
Date: Sat, 8 Feb 2025 19:42:22 -0800
From: comex <comexk@...il.com>
To: Theodore Ts'o <tytso@....edu>
Cc: "Dr. Greg" <greg@...ellic.com>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 Hector Martin <marcan@...can.st>,
 Dave Airlie <airlied@...il.com>,
 Jason Gunthorpe <jgg@...dia.com>,
 Greg KH <gregkh@...uxfoundation.org>,
 phasta@...nel.org,
 Christoph Hellwig <hch@....de>,
 Danilo Krummrich <dakr@...nel.org>,
 Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
 Abdiel Janulgue <abdiel.janulgue@...il.com>,
 daniel.almeida@...labora.com,
 aliceryhl@...gle.com,
 robin.murphy@....com,
 rust-for-linux@...r.kernel.org,
 Miguel Ojeda <ojeda@...nel.org>,
 Alex Gaynor <alex.gaynor@...il.com>,
 Boqun Feng <boqun.feng@...il.com>,
 Gary Guo <gary@...yguo.net>,
 Bj??rn Roy Baron <bjorn3_gh@...tonmail.com>,
 Benno Lossin <benno.lossin@...ton.me>,
 Andreas Hindborg <a.hindborg@...nel.org>,
 Trevor Gross <tmgross@...ch.edu>,
 Valentin Obst <kernel@...entinobst.de>,
 open list <linux-kernel@...r.kernel.org>,
 Marek Szyprowski <m.szyprowski@...sung.com>,
 airlied@...hat.com,
 "open list:DMA MAPPING HELPERS" <iommu@...ts.linux.dev>,
 DRI Development <dri-devel@...ts.freedesktop.org>
Subject: Re: On community influencing (was Re: [PATCH v8 2/2] rust: add dma
 coherent allocator abstraction.)

On Feb 8, 2025, at 12:44 PM, Theodore Ts'o <tytso@....edu> wrote:
> 
> including an upstream language
> community which refuses to make any kind of backwards compatibility
> guarantees, and which is *actively* hostile to a second Rust compiler
> implementation (I suspect because it might limit their ability to make
> arbitrary backwards-incompatble language changes).

Rust does, of course, make all sorts of backward compatibility guarantees for stabilized features.

The list of unstable features used by Rust for Linux is still long, but getting shorter.

https://github.com/Rust-for-Linux/linux/issues/2