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]. 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. 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. James [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).
