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
| ||
|
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
Powered by blists - more mailing lists