lkml.org 
[lkml]   [2022]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v9 12/27] rust: add `kernel` crate
    Linus Torvalds <torvalds@linux-foundation.org> writes:

    > On Mon, Sep 19, 2022 at 4:58 PM Linus Torvalds
    > <torvalds@linux-foundation.org> wrote:
    >>
    >> This is not some kind of "a few special things".
    >>
    >> This is things like absolutely _anything_ that allocates memory, or
    >> takes a lock, or does a number of other things.
    >
    > Examples of "number of other things" ends up being things like
    > "accessing user memory", which depending on what you are doing may be
    > very common too.
    >
    > And btw, it's not only about the (multiple kinds of) atomic regions.
    >
    > We have other context rules in the kernel too, like "does floating
    > point or vector unit calculations". Which you can actually do, but
    > only in a kernel_fpu_begin/kernel_fpu_end region.
    >
    > Now, the floating point thing is rare enough that it's probably fine
    > to just say "no floating point at all in Rust code". It tends to be
    > very special code, so you'd write it in C or inline assembly, because
    > you're doing special things like using the vector unit for crypto
    > hashes using special CPU instructions.

    I just want to point out that there are ways of representing things like
    the context you are running in during compile time. I won't argue they
    are necessarily practical, but there are ways and by exploring those
    ways some practical solutions may result.

    Instead of saying:
    spin_lock(&lock);
    do_something();
    spin_unlock(&lock);

    It is possible to say:
    with_spin_lock(&lock, do_something());

    This can be taken a step farther and with_spin_lock can pass a ``token''
    say a structure with no members that disappears at compile time that
    let's the code know it has the spinlock held.

    In C I would do:
    struct have_spin_lock_x {
    // nothing
    };

    do_something(struct have_spin_lock_x context_guarantee)
    {
    ...;
    }

    I think most of the special contexts in the kernel can be represented in
    a similar manner. A special parameter that can be passed and will
    compile out.

    I don't recall seeing anything like that tried in the kernel so I don't
    know if it makes sense or if it would get too wordy to live, but it is
    possible. If passing a free context parameter is not too wordy it would
    catch silly errors, and would hopefully leave more mental space for
    developers to pay attention to the other details of the problems they
    are solving.

    *Shrug* I don't know if rust allows for free parameters like that and
    if it does I don't know if it would be cheap enough to live.

    Eric

    \
     
     \ /
      Last update: 2022-09-20 17:56    [W:7.111 / U:0.460 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site