lkml.org 
[lkml]   [2021]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 00/13] [RFC] Rust support
    On Wed, Apr 14, 2021 at 01:21:52PM -0700, Linus Torvalds wrote:
    > On Wed, Apr 14, 2021 at 1:10 PM Matthew Wilcox <willy@infradead.org> wrote:
    > >
    > > There's a philosophical point to be discussed here which you're skating
    > > right over! Should rust-in-the-linux-kernel provide the same memory
    > > allocation APIs as the rust-standard-library, or should it provide a Rusty
    > > API to the standard-linux-memory-allocation APIs?
    >
    > Yeah, I think that the standard Rust API may simply not be acceptable
    > inside the kernel, if it has similar behavior to the (completely
    > broken) C++ "new" operator.
    >
    > So anything that does "panic!" in the normal Rust API model needs to
    > be (statically) caught, and never exposed as an actual call to
    > "panic()/BUG()" in the kernel.

    Rust has both kinds of allocation APIs: you can call a method like
    `Box::new` that panics on allocation failure, or a method like
    `Box::try_new` that returns an error on allocation failure.

    With some additional infrastructure that's still in progress, we could
    just not supply the former kind of methods at all, and *only* supply the
    latter, so that you're forced to handle allocation failure. That just
    requires introducing some further ability to customize the Rust standard
    library.

    (There are some cases of methods in the standard library that don't have
    a `try_` equivalent, but we could fix that. Right now, for instance,
    there isn't a `try_` equivalent of every Vec method, and you're instead
    expected to call `try_reserve` to make sure you have enough memory
    first; however, that could potentially be changed.)

    \
     
     \ /
      Last update: 2021-04-14 22:47    [W:4.195 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site