Android's new Bluetooth stack rewrite (Gabeldorsh) is written with Rust • Hacker News Board

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

#161

Post by qbasic_forever » Wed, Mar 31, 2021, 5:37 PM UTC

mondoshawan wrote: post #37

parwan98 wrote: post #10

Earlier quoted context omitted.

> fighting Broadcom's old, god-awful bluetooth code Correction: god-awful host side bluetooth code. There is still the bluetooth firmware residing on the BCMxxx chip (or Qualcomm chip) - >1MB of god-awfulerer closed-source code, half of it is in ROM (with limited number of available patch slots), full of bugs. You can see it crash from time to time in the kernel debug logs (and auto-restart itself)

On Glass, we actually went to Broadcom and had them on the ropes for fixing parts of their firmware. Sadly, we couldn't bring those fixes out of the closed source world of hardware, so it's still up to the system integrator to fight those battles...

Serious question, why doesn't Google build its own bluetooth & BLE chips? Please put some competition on Broadcoam and the like and either push them entirely out of the market (good riddance), or force them to step up their game.

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

#162

Post by oriolid » Wed, Mar 31, 2021, 5:39 PM UTC

shadowgovt wrote: post #119

oriolid wrote: post #99

Earlier quoted context omitted.

It's because Samsung can get away with selling total garbage. I work on an audio-related app, and a huge majority of the hacks in the app to work around bugs in phones are for different Samsung models. Still more than half of our users keep buying them.

This, but slightly revised: it's because Samsung is in the market of selling cheap hardware. Apple sells luxury products and part of their value-add is leverage with their vendors. Apple can come to a vendor and say "these are our constraints on what we are willing to buy . Here's testing benchmarks. You are required to meet them. Failure to do so voids the purchase contract." The vendor will then, of course, say "We…

> Samsung is in the market of selling cheap hardware

I'm not sure about this. There are people who pay >1000€ for their flagship phones and believe them to be premium products, but they are just as buggy as the cheap ones. Huge amount of CPU power and impressive camera specs, though.

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

#163

Post by arendtio » Wed, Mar 31, 2021, 5:40 PM UTC

From my experience the Android Bluetooth experience is much better than the Linux Bluetooth experience. Even my ancient Samsung S3 work better than a recently bought Bluetooth dongle for my desktop and I only bought the new dongle, because the experience with the onboard Bluetooth was so horrible.

Sometimes I wonder how a technology that is so common on modern devices is still so unreliable.

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

#164

Post by bluGill » Wed, Mar 31, 2021, 5:40 PM UTC

zozbot234 wrote: post #90

bluGill wrote: post #78

Earlier quoted context omitted.

Then C++ doesn't have classes either, you can put methods on structs though. Rust people keep saying there are not classes, but all a class needs it the ability to put methods on structs. Private access to some of the internals is often useful, but doesn't need to be enforced by the compiler.

The issue is not "structs" v. "classes" per se, it's things like inheritance, vtables and RTTI (also other C++ features like templates and exceptions), that need special ABI support in C++ for which there is no Rust-side equivalent. (meanwhile Rust traits are quite different from anything in C++, although they're used similarly)

None of those things are required for a class. I'll admit they are all useful at time, but all are abused.

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

#165

Post by sumtechguy » Wed, Mar 31, 2021, 5:41 PM UTC

mondoshawan wrote: post #48

rektide wrote: post #20

Why not BlueZ, that everyone else uses? Android feels like the land of Not Invented Here sometimes, to me. There might be good reasons, but often it feels like it's just Google trying to insure Android is as incompatible / different as possible from everything else that runs Linux. It doesn't help that almost none of the ChromeOS / Android subsystems or tools have not made it to any mainstream / regular Linux. They r…

GPL is the problem. Hardware vendors won't touch it with a 10k foot pole because of the requirement to redistribute patches. There's a history of wanting BSD licenses at Android's inception. If the BSD distributions hadn't run into problems relating to legal battles at the time, Android would be built on Mach with a BSD userland rather than Linux. Additionally, there was more vendor support and drivers for the Linux…

Also many hardware vendors use their stack to differentiate themselves from other competitors as at the end they tend to 'do' the same things. That stack keeps at bay people just copying their design wholesale and then undercutting their margin and using their drivers. Then even if they are willing, they many times included some lib they bought from someone else. They may even have the full code to use and have changed it as needed. But that 3rd party is usually some consulting group and guess what one of the very few things they sell is. It is a huge mess.

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

#166

Post by qbasic_forever » Wed, Mar 31, 2021, 5:43 PM UTC

tschellenbach wrote: post #101

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

Enormous spec crafted by committee. It's anything and everything to everyone, which means implementing the entire thing is a _serious_ undertaking. Add to that it's the kind of feature that's a cost center--people expect wireless stuff like headphones, etc. to just work and be there, it's not a glitzy feature that sells products. So there's zero incentive to innovate or spend time and money making it better. Hardware makers want cheaper chips, skimping on the implementation and software side helps make that happen.

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

#167

Post by londons_explore » Wed, Mar 31, 2021, 5:43 PM UTC

qbasic_forever wrote: post #161

mondoshawan wrote: post #37

Earlier quoted context omitted.

On Glass, we actually went to Broadcom and had them on the ropes for fixing parts of their firmware. Sadly, we couldn't bring those fixes out of the closed source world of hardware, so it's still up to the system integrator to fight those battles...

Serious question, why doesn't Google build its own bluetooth & BLE chips? Please put some competition on Broadcoam and the like and either push them entirely out of the market (good riddance), or force them to step up their game.

Building radio ASICs is a world rife with patents. Pretty much nobody new can enter the market.

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

#168

Post by oriolid » Wed, Mar 31, 2021, 5:43 PM UTC

steveklabnik wrote: post #129

oriolid wrote: post #111

Earlier quoted context omitted.

What's the difference between struct and class in C++? IIRC the standard says they're the same except that members are public by default on struct and private by default on class. You could as well argue that C++ doesn't have structs. The different allocation between structs and class objects in C# is a total head scratcher. Didn't it ever occur to the language designers that someone might want to choose how to alloc…

So, I dug into this a bit more, and you're right! https://www.fluentcpp.com/2017/06/13/the-real-difference-bet... Maybe it was the era that I learned C++ (which was in the 98 days), but I was taught something closer to this convention, and didn't realize until just now there was such little difference by the book. Just bundling some data together? Use a struct. Doing more? Use a class. I still think this distinction…

It certainly makes sense to use struct and class to indicate what the type's role is. It's just good to keep in mind to avoid the confusion when you find the struct that has only pure virtual functions as members.

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

#169

Post by Waterluvian » Wed, Mar 31, 2021, 5:44 PM UTC

qbasic_forever wrote: post #161

mondoshawan wrote: post #37

Earlier quoted context omitted.

On Glass, we actually went to Broadcom and had them on the ropes for fixing parts of their firmware. Sadly, we couldn't bring those fixes out of the closed source world of hardware, so it's still up to the system integrator to fight those battles...

Serious question, why doesn't Google build its own bluetooth & BLE chips? Please put some competition on Broadcoam and the like and either push them entirely out of the market (good riddance), or force them to step up their game.

Google's involvement in any kind of hardware is already a distraction from their core product line. Making their own chips is a distraction on a distraction.

Distraction might not be the right word but I can't conjure up the right one.

Hardware is one of the end goals for Apple, for example. For Google, Android hardware is not. It's just there to serve their goal of selling ads.

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

#170

Post by izacus » Wed, Mar 31, 2021, 5:44 PM UTC

SketchySeaBeast wrote: post #34

akersten wrote: post #18

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…

That's bizarre. I have a Samsung phone with Samsung Bluetooth earbuds and I've only ever experienced a single connection issue in the whole year I've owned them and they are a daily driver for me. I wonder what the difference is.

Samsung phones actually use their own Bluetooth stack not the one from AOSP Android. This is why the Bluetooth feature set sometimes doesn't match with the others.