lkml.org 
[lkml]   [2021]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 00/13] [RFC] Rust support
    Hi folks,

    "we will do less critical stuff, like device drivers, first".

    OK I mostly do device drivers. Kind of like it. So I'd like to provide
    feedback from that angle.

    On Fri, Apr 16, 2021 at 4:22 AM Wedson Almeida Filho
    <wedsonaf@google.com> wrote:

    > We don't intend to directly expose C data structures to Rust code (outside the
    > kernel crate). Instead, we intend to provide wrappers that expose safe
    > interfaces even though the implementation may use unsafe blocks. So we expect
    > the vast majority of Rust code to just care about the Rust memory model.

    I'm a bit worried about this.

    I am sure you are aware of this document:
    Documentation/process/stable-api-nonsense.rst

    We really like to change the internal APIs of the kernel, and it sounds to
    me like Rust really likes a rust-side-vs-C-side approach to APIs, requiring
    these wrappers to be written and maintained all over the place, and that
    is going to affect the mobility of the kernel-internal APIs and make them
    less mobile.

    If it means I need to write and review less patches related to NULL
    dereference and use-after-free etc etc, then it may very well be worth
    it.

    But as subsystem maintainer I'd like a clear picture of this wrapper
    overhead, what does it usually entail? A typical kernel API has
    vtable and a few variables, not much more than that.

    I go to patch 12/13 and I see things like this:

    +/// A descriptor of wrapped list elements.
    +pub trait GetLinksWrapped: GetLinks {
    + /// Specifies which wrapper (e.g., `Box` and `Arc`) wraps the list entries.
    + type Wrapped: Wrapper<Self::EntryType>;
    +}
    +
    +impl<T: ?Sized> GetLinksWrapped for Box<T>
    +where
    + Box<T>: GetLinks,
    +{
    + type Wrapped = Box<<Box<T> as GetLinks>::EntryType>;
    +}
    +
    +impl<T: GetLinks + ?Sized> GetLinks for Box<T> {
    + type EntryType = T::EntryType;
    + fn get_links(data: &Self::EntryType) -> &Links<Self::EntryType> {
    + <T as GetLinks>::get_links(data)
    + }
    +}

    My God. Lose the horrible CamelCase to begin with. I hope the
    language spec does not mandate that because our kernel C style
    does not use it.

    It becomes obvious that as subsystem maintainer for the Linux kernel
    a casual drive-by experience with Rust is not going to suffice by far.

    All subsystem maintainers are expected to understand and maintain
    wrappers like these, right? That means all subsystem maintainers need
    to be elevated to understand the above without effort if you wake them
    up in their sleep at 4 in the morning.

    This makes me a bit sceptic.

    Get me right, we are of course good at doing really complicated stuff,
    that's what engineers do. But we are not Iron Man. We need a clear
    way into understanding and maintaining wrappers and we need support
    with it when we don't understand it, so the kernel would need a Rust
    wrapper maintainer that we can trust to stay around for the long term,
    i.e. until their retirement, while actively teaching others for decades.
    For an example see how RCU is maintained.

    Developing trust in the people Miguel and Wedson is going to be more
    important than trust in Google the company for this.

    Yours,
    Linus Walleij

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