[Mesa-dev] Rust drivers in Mesa

[Eric Anholt]

On Fri, Oct 2, 2020 at 8:05 AM Dylan Baker <dylan at pnwbakers.com> wrote:
>
> I have serious concerns about cargo and crate usage. Cargo is basically npm for rust, and shares all of the bad design decisions of npm, including linking multiple versions of the same library together and ballooning dependency lists that are fetched intrigued from the internet. This is both a security problem and directly in conflict with meson's design off one and only one version of a project. And while rust prevents certain kinds of bugs, it doesn't prevent design bugs or malicious code. Add a meson developer the rust community has been incredibly hard to work with and basically hostile to every request we've made "cargo is hour you build rust", is essentially the answer we've gotten from them at every turn. And if you're not going to use cargo, is rust really a win? The standard library is rather minimal "because just pull in 1000 crates". The distro people can correct me if I'm wrong, but when librsvg went to rust it was a nightmare, several distros went a long time without updates because of cargo.

(I am not currently advocating for cargo usage, but...)

The standard library is large compared to what we currently allow for
Mesa dependencies (libexpat, libz, libdrm basically).  First thought I
had was that my hash table/set is garbage compared to theirs, and we
could probably just wrap rust's with my C API and get a win for
compiler perf.  Having to write u_dynarray-using code makes one wish
we had Vec<>.  util/os_socket.c?  We write all sorts of stuff to work
around how we have no standard library worth speaking of currently,
and time we spend optimizing hash_table.c and fnv1 (or oh wait
xxhash32 or is that one actually best...) is time that we're not
getting to spend on making graphics code better.

If you're worried about cargo deps, introduce a cargo lockfile, even
though we're a library.  Lockfiles are for rust code used as a rust
library, I see no reason not to lock when our library has a C
interface.  Then you don't have the multiple deps or random versions
thing, it's up to us what we want to use, even if you're downloading
git of that hash off the internet.

Yes, there's the "if you blindly uprev, you can pull in malicious
deps" thing.  I feel pretty good about that given the rate of
dependency compromise attacks I've seen detected in npm/cargo/etc.,
compared to the rate of CVEs we could generate if we chose to aim a
fuzzer basically anywhere in our codebase.