Live data from Hacker News

Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

android.googlesource.com

141–150 of 393 posts

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#141
post #30

The Android IPC driver (binder) is also being re-written in rust. It takes advantage of the upcoming kernel driver rust support in Linux. It is an obvious choice for a memory safe re-write since all android processes (including sandboxed ones) have access to binder

This is a big f'n deal for Android, IMHO

In the "big deal" sense, i'm always curious in what way. Eg is it a source of constant problems? Where not only a rewrite, but specifically a rewrite in Rust, would prevent a lot of issues?

Or is it more of a "What if" thing? Ie there's not many problems currently, but the liability is a huge deal?

to be clear i work in Rust, use it for all my projects, etc - i'm a fanboy, but i also recognize there's a lot of hype. I'm always keeping an eye out for the Rewrite It In Rust (RIIR?) meme vs actual needs.

Which isn't to say that i think people _need_ to have a reason to use Rust, i use it for everything because i (and my team) prefer it - but i think the meme is destructive.. so i'm always looking for it heh.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#142
post #102

Earlier quoted context omitted.

Possibly but Python is a completely different level of programming too. I do wonder if Rust is easier or harder than other comparable languages like C / C++ when the person has no prior knowledge of programming. I would say just the ease of having a hello world and the ease of the Rust book would make it easier to get to grips with. No dealing with complex build systems and compiler flags at the start

The Rust book as currently written assumes that the user has some programming experience. That's mainly b/c there hasn't been much of any experimentation in teaching Rust as a first time programming language. Although obviously it's been done for C++ and even C, so it ought to be quite doable, if perhaps with a bit of a "learn programming the hard way" style.

That's true. It doesn't introduce base concepts for example.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#143

I'm always curious why bluetooth is such a terrible piece of technology. Did anyone write blogposts analyzing what went wrong?

It's pretty simple really. It tries to do a lot of complicated things, and it's underspecified so it's possible to have compliant devices that behave wildly differently between vendors. It also rarely breaks compatibility so there's a lot of cruft for ancient devices.

This is the exact reason it is challenging. There is a lot of variance in how each manufacturer implements it. You might compare it to the browser wars of old - you've got many different players adding various extensions in different ways etc. The actual radio technology and low power consumption are phenomenal, the problems arise mostly around protocol implementation oddities.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#144

I'm always curious why bluetooth is such a terrible piece of technology. Did anyone write blogposts analyzing what went wrong?

From what I know from having worked at Nokia, it's simply the result of design by committee where the committee was made up of mutually very hostile hardware (mostly) companies not particularly good at software (that's how Nokia failed in a nutshell), telcos, chipset manufacturers, hardware manufacturers, etc. And I mean hostile as in looking to squeeze each other for patent licensing, competing for the same customers, and suppliers. All this happened in an ecosystem that also produced such monstrosities as gprs, 3G, 4G, etc. Ericsson and Nokia were on top of the market when they created bluetooth and had a relatively big vote in these committees.

Each of those standards were burdened with lots of little features to cater for the needs (perceived or real) of each of the committee members. It's a very similar dynamic to what happened to bluetooth. A lot of 3G stuff never really got any traction. Especially once Apple and Google decided that IP connectivity was the only thing they needed from 3G/4G modems and unceremoniously declined to even bother to support such things as videocalls over 3G. Apple did Facetime instead and in the process also strangled SMS and cut out the middlemen (operators) from the revenue. Google was a bit slower but on Android a lot of 3G features were never really implemented as they were mostly redundant if you had a working internet connection, fully featured SDKs, and a modern web browser.

It's the same for a lot of early bluetooth features. Lots of stuff you can do with it; lots of vendors with half broken implementations with lots of bugs; decades of workarounds for all sorts of widely used buggy implementations; etc. It kind of works but not great and making it work great in the presence of all those not so great products is kind of hard.

Just a long way of saying that bluetooth is so convoluted and complicated is because the people that built it needed it to be that way more badly than they needed for it to be easy to implement (including by others). At this point it's so entrenched that nothing else seems to be able to displace it. I'm not even sure of people actively putting time and resources in even trying to do that. I guess you could but your product just wouldn't work with any phone or laptop in the market. Which if you make e.g. headphones is kind of a non-starter. It's Bluetooth or nothing. I wouldn't be surprised if Apple considered this at some point and then ended up not doing it. They have a history of taking good ideas and then creating proprietary but functional implementations of those ideas.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#145

Earlier quoted context omitted.

> I do wonder if Rust is easier or harder than other comparable languages like C / C++ when the person has no prior knowledge of programming. I can answer this because I previously taught the course in C and C++. The students supposedly have some knowledge of Java but they seem to always have forgotten all of it when they reach me. Students learning C use all of the footguns you can imagine. The biggest problem for t…

NOT TRUE! You are doing it wrong If you are manually managing memory on Modern C++. C++ has RAII built in even before Rust came to the scene. I've never had a situation where I had to manage memory manually during my professional career in C++ If your students face seg faults, please show them Valgrind. Valgrind is better than GDB when it comes to seg faults. It can show you where exactly error occurred. Edit: Oh I g…

I believe that statement from the person you're replying to was in comparison to the issues with teaching C not C++

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#146

This is great news. Hopefully it fixes a lot of the jank that I've always experienced with Android Bluetooth. I don't think I've ever had a smooth experience - even with a supposedly flagship device (Pixel 4a!) I've encountered all of the following problems: * Devices getting stuck at max volume (thankfully not headphones) * Devices getting stuck at really low volumes * Devices randomly switching between absolute vol…

All my Bluetooth woes from iPhone finally went away when I got a Pixel last year. The iPhone is still here and being used, but not for exercising due to the connectivity issues.

I think it’s just Bluetooth itself being cursed.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#147

Earlier quoted context omitted.

I still find it buggy on my iPhone 12 Pro, as a user at least. Often says 'connected' to my headphones (Sony WH-100XM3's) when it's not, connecting to Alexa devices to stream audio often fails and requires a reboot to connect properly. I can't believe Bluetooth is still such a pain in the bum in 2021.

Buggy Bluetooth on the other end... Alexa is running Linux, and the Sony is probably some custom bluetooth stack. Once you move to all Apple bluetooth, things really smooth out. It seems that Apple does way more testing/validating of their Bluetooth stack.

I had the idea in my head (so take with a grain of salt) that parts of the BT stack are underspecified such that different implementations tend to have slightly different interpretations of the standard, so the problem isn't even which vendor you use so much as going all-in on any single vendor so the devices all agree on which reading to use.

Although of course Apple might well be better anyways; one would hope that billions of dollars in R&D plus caring about quality makes a difference.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#148
post #31

Earlier quoted context omitted.

I suspect that Zig will still end up eclipsing Rust - not because it's a "more powerful" language, but because it's much easier to learn. Lower barriers of entry seem to matter more than mere "power" - see Common Lisp's multi-decade feature lead being ignored, and Python leapfrogging other more capable languages (Common Lisp) or equally capable ones that came first (Ruby) due to ease-of-use.

Zig is too uninteresting to eclipse anything. It's the same problem as D's -betterC option. It's not better-enough to motivate switching away from C in places where C is still used, and it's far too stripped down & basic to attract the majority that's gone to C++, Rust, Go, ObjC, or Swift (or even "full" D). It doesn't offer much to justify switching costs. If C++11 had never happened then maybe Zig would attract the…

Zigs lack of operator overloading means math code will be illegibly gibberish, which kills any possible interest I had in it.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#149

Earlier quoted context omitted.

Do you have any more info about ROM patch slots? I have never heard of this before. I assume this is a small amount of r/w memory that is somehow overlaid over specific locations in the ROM?

Correct. It's a small table of: address1, 4 bytes overlay data address2, 4 bytes overlay data etc The data is overlayed over the specified addresses, in runtime. On some chips its 8 bytes instead of 4. On a typical Broadcom/Cypress chip you have 128 or 256 entries. By the time the chip is 2-3 years in the market and still getting firmware updates, ~98% of them are used by existing firmware, so there are only 5-10 fre…

> Case in point: the Broadcom/Cypress BCM43455 chip on the raspberry pi is almost out of patch entries. Broadcom have switched to their usual tactic of stalling for years on known, reproducible bug reports.

And it's still really buggy. I had to write a service on the RPI and the only way to reliably connect was to restart bluetooth before every attempt.

That kind of fix makes a person feel dirty.

Re: Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust

#150
Gah. Just two days ago I finished what must have been our fourth rewrite of Kotlin code to interface with Android BLE. It's a complete trial by fire experience. Various medium and other blogs on the net are a morass of "find the true information amongst the disinformation". If I had a nickel for every "just put a delay here" so called solutions.

We have two apps, one that communicates over many variously configured characteristics, and another that uses less characteristics but pushes/receives just as fast as I can get it to go in big bursts.

The edge cases around connect/disconnect events are the most frustrating and most difficult to reliably debug and gain confidence your implementation is robust. Oh, and don't forget that just because it works on your Samsung, doesn't mean it works on your Moto.

Assuming this new implementation is indeed much better (and not just swapping one pile of surprises for a new and shiny, but different, pile of surprises) my hat is off to the folks behind this. You get a big fat atta-whatever for making the world a better place, even if I wish it had happened 4 years ago.

Post reply on HN