btleplug
Rust-for-Linux
Our great sponsors
btleplug | Rust-for-Linux | |
---|---|---|
9 | 79 | |
678 | 3,769 | |
4.3% | 1.9% | |
7.5 | 0.0 | |
20 days ago | 3 days ago | |
Rust | C | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
btleplug
-
Just an innocent mistake
In case someone is curious: https://github.com/deviceplug/btleplug/pull/279/files
-
Is the Rust ecosystem capable of making a cross-platform mobile game with p2p Bluetooth yet?
Is something wrong with https://github.com/deviceplug/btleplug or you haven't found it? You could also use bindings to platform libraries like https://github.com/microsoft/windows-rs and https://github.com/rust-mobile/ndk if btleplug doesn't have something fundamental to you.
-
Deldo is a sex toy control and teledildonics mode for Emacs
One of the worst/best parts of buttplug is that I ended up needed to maintain my own Bluetooth LE library: btleplug (https://github.com/deviceplug/btleplug).
Worst because working with bluetooth is always THE WORST, best because of the submissions and community that've grown around it.
There's 2 types of PRs to btleplug:
- People going "here's a PR but uh, why is the library named btleplWAIT WHAT"
- People going "here is a PR specifically to fix something in Buttplug thank you"
- btleplug (cross-platform bluetooth LE rust library) v0.8 released, now with async!
-
BLEZ - Asynchronous interface to official Bluetooth Low Energy APIs on Linux (BlueZ)
"In its dev branch"
-
Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust
I've always been annoyed at the cross-platform story for Bluetooth. GATT is one of my favorite protocols because it is so simple, but writing simple code against this simple protocol is _not_ portable:
iOS and macOS have CoreBluetooth, Linux has BlueZ, Windows has Windows.Devices.Bluetooth and Android has android.bluetooth.
I've seen a few projects trying to fix this, like https://github.com/deviceplug/btleplug, and I hope one of them becomes production ready.
-
Buttplug-rs Hits V1 Milestone
But, that's an ongoing problem. In terms of "done", I think the next big milestone will be mobile app support. We work on mobile web browsers in a couple of different ways, but Buttplug still needs app support, both native and for things like cordova/react native/etc... The biggest issue there at the moment lies in our bluetooth library (btleplug, https://github.com/deviceplug/btleplug), because getting the FFI via JNI to android is going to suck (even though I can crib off Servo's WebBluetooth impl, which worked on Android).
Rust-for-Linux
-
The Linux Kernel Prepares for Rust 1.77 Upgrade
At least according to the Github's language breakdown for https://github.com/Rust-for-Linux/linux, C is still 98.3% of the repository, and Rust is in the 0.1% of "others".
Rust is backwards compatible when you stick to stable features, but the kernel uses unstable features that can and do incur breaking changes.
-
Mark Russinovich: “Working towards enabling Windows driver development in Rust”
> How would this work?
Don't know exactly what you're asking.
> And why would it be a better idea?
Poorly written device drivers are a significant attack vector. It's one of the reasons Linux is now exploring using Rust for its own device drivers.[0] You may be asking -- why Rust and not some other language? Rust has many of the performance and interoperability advantages of C and C++, but as noted, makes certain classes of memory safety issues impossible. Rust also has significant mindshare among systems programming communities.
-
The Linux Kernel Module Programming Guide
Ctrl-F "rust"
https://rust-for-linux.com/ links to LWN articles at https://lwn.net/Kernel/Index/#Development_tools-Rust that suggest that only basic modules are yet possible with the rust support in Linux kernels 6.2 and 6.3.
Rust-for-linux links to the Android binder module though:
> Android Binder Driver: This project is an effort to rewrite Android's Binder kernel driver in Rust.
> Motivation: Binder is one of the most security and performance critical components of Android. Android isolates apps from each other and the system by assigning each app a unique user ID (UID). This is called "application sandboxing", and is a fundamental tenet of the Android Platform Security Model.
> The majority of inter-process communication (IPC) on Android goes through Binder. Thus, memory unsafety vulnerabilities are especially critical when they happen in the Binder driver
... "Rust in the Linux kernel" (2021) https://security.googleblog.com/2021/04/rust-in-linux-kernel... :
> [...] We also need designs that allow code in the two languages to interact with each other: we're particularly interested in safe, zero-cost abstractions that allow Rust code to use kernel functionality written in C, and how to implement functionality in idiomatic Rust that can be called seamlessly from the C portions of the kernel.
> Since Rust is a new language for the kernel, we also have the opportunity to enforce best practices in terms of documentation and uniformity. For example, we have specific machine-checked requirements around the usage of unsafe code: for every unsafe function, the developer must document the requirements that need to be satisfied by callers to ensure that its usage is safe; additionally, for every call to unsafe functions (or usage of unsafe constructs like dereferencing a raw pointer), the developer must document the justification for why it is safe to do so.
> We'll now show how such a driver would be implemented in Rust, contrasting it with a C implementation. [...]
This guide with unsafe rust that calls into the C, and then with next gen much safer rust right next to it would be a helpful resource too.
What of the post-docker container support (with userspaces also written in go) should be cloned to rust first?
-
The state of Flatpak security: major Projects are the worst?
Rust-for-Linux issue tracker
- rust devs in a nutshell
-
Rustproofing Linux (Part 1/4 Leaking Addresses)
Also, there already exists both issue: https://github.com/Rust-for-Linux/linux/issues/479
Yes, I definitely agree that it's a problem that pr_info implicitly wraps its arguments in unsafe {}. I wrote my own Pull Request with a trival fix.
-
how to compile a rust "hello world" with kernel 6.1?
Note that this template won't work with Linux 6.1, which has very minimal Rust support. You'll want the RustForLinux tree, or maybe Linux 6.2.
-
Rust in the 6.2 Kernel
> Also we’re bringing NPM style supply chain problems to the kernel now?
Nope. They've thought that through.
(In fact, cargo is only used to build test helpers. https://github.com/Rust-for-Linux/linux/blob/rust/Documentat...)
What are some alternatives?
buttplug-rs - Rust Implementation of the Buttplug Sex Toy Control Protocol
jakt - The Jakt Programming Language
gccrs - GCC Front-End for Rust
rfcs - RFCs for changes to Rust
rustig - A tool to detect code paths leading to Rust's panic handler
dafny - Dafny is a verification-aware programming language
PrawnOS - Libre Mainline Kernel and Debian for arm laptops
koka - Koka language compiler and interpreter
no-panic - Attribute macro to require that the compiler prove a function can't ever panic
cxx - Safe interop between Rust and C++
rustc_codegen_gcc - libgccjit AOT codegen for rustc
web-libusb