linux-kernel - Re: Rust kernel policy

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: <2cbxfvvsau5sobm3zo5ds7u26jeiskxs6cavp5a7hbokjisobi@2ybqbl6iry6k>
Date: Sat, 22 Feb 2025 10:03:41 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Theodore Ts'o <tytso@....edu>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, 
	James Bottomley <James.Bottomley@...senpartnership.com>, Christoph Hellwig <hch@...radead.org>, 
	rust-for-linux <rust-for-linux@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org>, 
	Greg KH <gregkh@...uxfoundation.org>, David Airlie <airlied@...il.com>, linux-kernel@...r.kernel.org, 
	ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

On Wed, Feb 19, 2025 at 12:06:23PM -0500, Theodore Ts'o wrote:
> On Wed, Feb 19, 2025 at 05:44:16PM +0100, Miguel Ojeda wrote:
> > Hmm... I am not sure exactly what you mean here. Are you referring to
> > Wedson's FS slides from LSF/MM/BPF? i.e are you referring to Rust
> > signatures?
> > 
> > If yes, those signatures are manually written, they are not the
> > generated bindings. We typically refer to those as "abstractions", to
> > differentiate from the generated stuff.
> 
> The problem with the bindings in Wedson's FS slides is that it's
> really unreasonable to expect C programmers to understand them.  In my
> opinion, it was not necessarily a wise decision to use bindings as
> hyper-complex as a way to convince C developers that Rust was a net
> good thing.

You keep talking about how the problem was Wedson's talk, but really the
problem was you derailing because you were freaking out over something
you didn't understand.

The example was fine. It wasn't overly complicated.

You've been an engineer for decades, taking in and digesting new
information about complex systems is something we have to do on a
regular basis. A little new syntax shouldn't be giving you that much
trouble; come on.

> I do understand (now) what Wedson was trying to do, was to show off
> how expressive and powerful Rust can be, even in the face of a fairly
> complex interface.  It turns out there were some good reasons for why
> the VFS handles inode creation, but in general, I'd encourage us to
> consider whether there are ways to change the abstractions on the C
> side so that:

It wasn't a "gentle introduction to Rust" talk. You can get that
anywhere.

It was a talk _specific to the VFS_, so "how does Rust cope with core
VFS interfaces" was precisely the point of the talk.

If you wanted to take up that much time in our presentation, you
should've prepared a bit better by aquiring at least a bit of
familiarity with Rust syntax beforehand. You shouldn't need to be
spoonefed, the rest of us have done that on our own time.

Just please try to have some etiquette.