lkml.org 
[lkml]   [2021]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 00/13] [RFC] Rust support
    On Thu, Apr 15, 2021 at 08:58:16PM +0200, Peter Zijlstra wrote:
    >
    > This; can we mercilessly break the .rs bits when refactoring? What
    > happens the moment we cannot boot x86_64 without Rust crap on?
    >
    > We can ignore this as a future problem, but I think it's only fair to
    > discuss now. I really don't care for that future, and IMO adding this
    > Rust or any other second language is a fail.

    I believe this is the most important question and we really need
    a honest answer in advance: where exactly is this heading? At the moment
    and with this experimental RFC, rust stuff can be optional and isolated
    but it's obvious that the plan is very different: to have rust all
    around the standard kernel tree. (If not, why is the example driver in
    drivers/char/ ?)

    And I don't see how the two languages might coexist peacefully without
    rust toolchain being necessary for building any kernel useful in
    practice and anyone seriously involved in kernel development having to
    be proficient in both languages. Neither of these looks appealing to
    me.

    The dependency on rust toolchain was exactly what made me give up on
    building Firefox from mercurial snapshots few years ago. To be able to
    build them, one needed bleeding edge snapshots of rust toolchain which
    my distribution couldn't possibly provide and building them myself
    required way too much effort. This very discussion already revealed that
    rust kernel code would provide similar experience. I also have my doubts
    about the "optional" part; once there are some interesting drivers
    written in rust, even if only in the form of out of tree modules, there
    will be an enormous pressure on distributions, both community and
    enterprise, to enable rust support. Once the major distributions do,
    most others will have to follow. And from what I have seen, you need
    rust toolchain for build even if you want to only load modules written
    in rust.

    The other problem is even worse. Once we have non-trivial amount of rust
    code around the tree, even if it's "just some drivers", you cannot
    completely ignore it. One example would be internal API changes. Today,
    if I want to touch e.g. ethtool_ops, I need to adjust all in tree NIC
    drivers providing the affected callback and adjust them. Usually most of
    the patch is generated by spatch but manual tweaks are often needed here
    and there. In the world of bilingual kernel with nontrivial number of
    NIC drivers written in rust, I don't see how I could do that without
    also being proficient in rust.

    Also, how about maintainers and reviewers? What if someone comes with
    a new module under foo/ or foo/bar/ and relevant maintainer does not
    know rust or just not well enough to be able to review the submission
    properly? Can they simply say "Sorry, I don't speak rust so no rust in
    foo/bar/"? Leaf drivers are one thing, how about netfilter matches and
    targets, TCP congestion control algorighms, qdiscs, filesystems, ...?
    Having kernel tree divided into "rusty" and "rustfree" zones does not
    sound like a great idea. But if we don't want that, do we expect every
    subsystem maintainer and reviewer to learn rust to a level sufficient
    for reviewing rust (kernel) code? Rust enthusiasts tell us they want to
    open kernel development to more people but the result could as well be
    exactly the opposite: it could restrict kernel development to people
    proficient in _both_ languages.

    As Peter said, it's not an imminent problem but as it's obvious this is
    just the first step, we should have a clear idea what the plan is and
    what we can and should expect.

    Michal

    \
     
     \ /
      Last update: 2021-04-16 10:17    [W:5.143 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site