Hi
On Fri, 02 Oct 2020 08:04:43 -0700 "Dylan Baker" 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
