Re: [LSF/MM TOPIC] Rust

[Matthew Wilcox <willy@infradead.org>]

On Wed, Jan 24, 2024 at 09:26:34AM -0500, James Bottomley wrote:
> On Tue, 2024-01-23 at 19:09 +0000, Matthew Wilcox wrote:
> > >   - The use of outside library code: Historically, C code was
> > > either written for userspace or the kernel, and not both. But
> > > that's not particularly true in Rust land (and getting to be less
> > > true even in C land); should we consider some sort of structure or
> > > (cough) package management? Is it time to move beyond ye olde cut-
> > > and-paste?
> > 
> > Rust has a package manager.  I don't think we need kCargo.  I'm not
> > deep enough in the weeds on this to make sensible suggestions, but if
> > a package (eg a crypto suite or compression library) doesn't depend
> > on anything ridiculous then what's the harm in just pulling it in?
> 
> The problem with this is that it leads to combinatoric explosions and
> multiple copies of everything[1].

OK, but why do we care?  We still have buffer_heads in the kernel (v1.0
of the block layer abstraction) while also have bios, iomap and numerous
NIH in various filesystems.  I don't even know if it's going to be
quantitatively worse.

> For crypto in particular the last
> thing you want to do is pull some random encryption routine off the
> internet, particularly if the kernel already supplies it because it's
> usually not properly optimized for your CPU and it makes it a nightmare
> to deduce the security properties of the system.

That seems like a strawman.  Why is it _so_ much worse to have your kernel
compromised than your web browser, your email client, or your corporate
authentication provider?  Why would we allow code in that pulls in random
shit from the internet instead of the vetted stuff on crates.io?

> However, there's nothing wrong with a vetted approach to this: keep a
> list of stuff rust needs, make sure it's properly plumbed in to the
> kernel routines (which likely necessitates package changes) and keep it
> somewhere everyone can use.

... like crates.io.  Why are we better at this than they are?

> [1] just to support this point, I maintain a build of element-desktop
> that relies on node (which uses the same versioned package management
> style rust does).  It pulls in 2115 packages of which 417 are version
> duplicates (same package but different version numbers).

I'd suggest that node.js has a very different approach from crates.io.
I don't see there being a rust left-pad.