Hi On Fri, 02 Oct 2020 08:04:43 -0700 "Dylan Baker" <dy...@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 u pdates because of cargo. I can't say much about meson, but using Rust has broken the binaries of several packages on i586 for us; which consequently affects Gnome and KDE. [1][2] Rust uses SSE2 instructions on platforms that don't have them. There's a proposed workaround, but it's not yet clear if that's feasible in practice. Best regards Thomas [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1162283 [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1077870 > > On the meson front cargo is incredibly hard to integrate with meson, it's > essentially like calling cmake in autotools. > > Dylan > > On Thu, Oct 1, 2020, at 18:35, Alyssa Rosenzweig wrote: > > Hi all, > > > > Recently I've been thinking about the potential for the Rust programming > > language in Mesa. Rust bills itself a safe system programming language > > with comparable performance to C [0], which is a naturally fit for > > graphics driver development. > > > > Mesa today is written primarily in C, a notoriously low-level language, > > with some components in C++. To handle the impedance mismatch, we've > > built up a number of abstractions in-tree, including multiple ad hoc > > code generators (GenXML, NIR algebraic passes, Bifrost disassembler). A > > higher level language can help avoid the web of metaprogramming and > > effect code that is simpler and easier to reason about. Similarly, a > > better type system can aid static analysis. > > > > Beyond abstraction, Rust's differentiating feature is the borrow checker > > to guarantee memory safety. Historically, safety has not been a primary > > concern of graphics drivers, since drivers are implemented as regular > > userspace code running in the process of the application calling them. > > Unfortunately, now that OpenGL is being exposed to untrusted code via > > WebGL, the driver does become an attack vector. > > > > For the time being, Mesa attempts to minimize memory bugs with defensive > > programming, safe in-tree abstractions (including ralloc), and static > > analysis via Coverity. Nevertheless, these are all heuristic solutions. > > Static analysis is imperfect and in our case, proprietary software. > > Ideally, the bugs we've been fixing via Coverity could be caught at > > compile-time with a free and open source toolchain. > > > > As Rust would allow exactly this, I see the primary benefit of Rust in > > verifying correctness and robustness, rather than security concerns per > > se. Indeed, safety guarantees do translate well beyond WebGL. > > > > Practically, how would Rust fit in with our existing C codebase? > > Obviously I'm not suggesting a rewrite of Mesa's more than 15 million > > lines of C. Instead, I see value in introducing Rust in targeted parts > > of the tree. In particular, I envision backend compilers written in part > > in Rust. While creating an idiomatic Rust wrapper for NIR or Gallium > > would be prohibitively costly for now, a backend compiler could be > > written in Rust with IR builders exported for use of the NIR -> backend > > IR translator written in C. > > > > This would have minimal impact on the tree. Users that are not building > > such a driver would be unaffected. For those who _are_ building Rust > > code, the Rust compiler would be added as a build-time dependency and > > the (statically linked) Rust standard library would be added as a > > runtime dependency. There is concern about the Rust compiler requiring > > LLVM as a dependency, but again this is build-time, and no worse than > > Mesa already requiring LLVM as a runtime dependency for llvmpipe and > > clover. As for the standard library, it is possible to eliminate the > > dependency as embedded Rust does, perhaps calling out to the C standard > > library via the FFI, but this is likely quixotic. I do regret the binary > > size increase, however. > > > > Implications for the build system vary. Rust prefers to be built by its > > own package manager, Cargo, which is tricky to integrate with other > > build systems. Actually, Meson has native support for Rust, invoking the > > compiler directly and skipping Cargo, as if it were C code. This support > > is not widely adopted as it prevents linking with external libraries > > ("crates", in Rust parlance), with discussions between Rust and Meson > > developers ending in a stand-still [1]. For Mesa, this might be just > > fine. Our out-of-tree run-time dependencies are minimal for the C code, > > and Rust's standard library largely avoids the need for us to maintain a > > Rust version of util/ in-tree. If this proves impractical in the > > long-term, it is possible to integrate Cargo with Meson on our end [2]. > > > > One outstanding concern is build-time, which has been a notorious > > growing pain for Rust due to both language design and LLVM itself [3], > > although there is active work to improve both fronts [4][5]. I build > > Mesa on my Arm laptop, so I suppose I'd be hurt more than many of us. > > There's also awkward bootstrapping questions, but there is work here too > > [6]. > > > > If this is of interest, please discuss. It's clear to me Rust is not > > going away any time soon, and I see value in Mesa embracing the new > > technology. I'd like to hear other Mesa developers' thoughts. > > > > Thanks, > > > > Alyssa > > > > [0] https://www.rust-lang.org/ > > [1] https://github.com/mesonbuild/meson/issues/2173 > > [2] https://gitlab.gnome.org/GNOME/fractal/-/blob/master/meson.build > > [3] https://pingcap.com/blog/rust-compilation-model-calamity/ > > [4] > > https://blog.mozilla.org/nnethercote/2020/04/24/how-to-speed-up-the-rust-compiler-in-2020/ > > [5] https://github.com/bjorn3/rustc_codegen_cranelift > > [6] https://github.com/thepowersgang/mrustc > > > > _______________________________________________ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > > > > *Attachments:* > > * signature.asc > > -- > Dylan Baker > dy...@pnwbakers.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
