On Wed, Jul 07, 2021 at 02:50:54PM +0200, Greg Kroah-Hartman wrote: > On Wed, Jul 07, 2021 at 02:33:57PM +0200, Miguel Ojeda wrote: > > Now, if you are OK with non-hardware modules, you can take a look at > > Rust Binder (last patch in the series) which is a non-trivial module > > and it is already working. > > Cool, does it actually pass the binder self-tests that the Android > systems have for the codebase? We haven't run the Android tests yet because they depend on an Android-specific service (servicemanager) running and other Android-specific libraries. What we are doing instead is adding binder tests that don't depend on anything Android-specific; in fact, we are putting them in tools/testing/selftests/binder so that they can run on any vanilla system. The commit is available here: https://github.com/wedsonaf/linux/commit/f90ec49be9207fa765f07ad1071210ad871712ac The tests are written in C and run successfully against both C and Rust drivers. I still have another ~20 tests that I wrote in another harness that I will convert to selftests soon, but the two together I believe have more coverage than the ones in Android. We also have a trivial latency benchmark (ping with no payload) where the Rust version performs better than the C one. The benchmark is available here: https://github.com/wedsonaf/linux/commits/ping > Last I looked at this thing, it was not > feature-complete compared to the in-kernel binder code, has that been > resolved and the needed filesystem changes added? It is not feature-complete in comparison to the C one just yet, it is missing a few things but not for any fundamental reason -- we were mostly focusing on the kernel crate and tests. Miguel's point is that it does implement the vast majority of binder features and is non-trivial, so it could be used as evidence that useful kernel drivers can be built with Rust; not just "transpiled" from C, but written with the Rust safety guarantees. Cheers, -Wedson
