linux-kernel - Re: [RFC PATCH 0/7] Rust Socket abstractions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <02d0771b-ba9b-4bed-afe5-9ece5100dadf@lunn.ch>
Date:   Thu, 17 Aug 2023 21:14:36 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc:     Michele Dalle Rive <dallerivemichele@...il.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Miguel Ojeda <ojeda@...nel.org>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Wedson Almeida Filho <wedsonaf@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
        Björn Roy Baron <bjorn3_gh@...tonmail.com>,
        Benno Lossin <benno.lossin@...ton.me>,
        Alice Ryhl <aliceryhl@...gle.com>,
        Davide Rovelli <davide.rovelli@....ch>,
        rust-for-linux@...r.kernel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, patches@...ts.linux.dev
Subject: Re: [RFC PATCH 0/7] Rust Socket abstractions

> If I understood correctly from Zulip, you cannot (right now) show your
> use case because it is confidential and therefore you cannot upstream
> it

Is there a clear path for it to become public and mergable?

There is also a general trend that code developed behind closed doors
needs a complete re-write when made public and reviewed by mainline
developers. And that rewrite could involve the APIs to other
subsystems, like sockets. So any API you define now with a 'toy' in
kernel user, could in fact be totally useless by the time your real
target gets merged.

As Jon pointed out, we kernel maintainers need to help people coming
from a different background. Within the community it is well known
that internal APIs are unstable. Any developer can change any API, and
all its in kernel users if there is a need to do so. This makes
maintaining out of tree modules hard. There are a number of 'vendor
crap' drivers which do do this, with lots of ugly code to work around
differences between kernel versions. To some extent, that works
because the C APIs are not that volatile. My guess is, the Rust APIs
are going to be a lot more volatile for a number of years while
developers figure out what good APIs look like, and rework them again
and again, and again. Anybody trying to maintain an out of tree rust
module is going to be in a world of pain. In tree however, benefits
from the fast that any developer who wants to change an API needs to
also change all users...

       Andrew