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

#171

Post by LASR » Wed, Mar 31, 2021, 5:45 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.

I've heard RF-anything is quite hard to get right. One of the reasons why Intel was dumped for XMM modems is because they were just slower than Qualcomm.

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

#172

Post by pjmlp » Wed, Mar 31, 2021, 5:45 PM UTC

kllrnohj wrote: post #97

pjmlp wrote: post #51

Nice to see this. Sadly the Android team, while taking this safety steps, it keeps using unsafe C userspace for NDK APIs. Security is as good as the weakest link.

> Sadly the Android team, while taking this safety steps, it keeps using unsafe C userspace for NDK APIs. You phrase this as a negative but it's overwhelmingly a positive. Imagine how difficult it'd be to write an app using the NDK in Rust if the NDK had been C++ instead. The C ABI remains by far the most portable & common target. Everything can call it.

It is a bit hard to talk about safety when everything one has to play is an API that allows for all the usual stuff that C is known to cause.

Everything can call it, and everyone has to redo the safety work.

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

#173

Post by ModernMech » Wed, Mar 31, 2021, 5:45 PM UTC

cultyyy123 wrote: post #135

ModernMech wrote: post #115

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…

You still need to teach what the delete keyword is and how memory management works in C++. There's tons of code out there not written with smart pointers.

And yes we use valgrind, but it's important not to overload students who are new to programming. Students tend to reach for withdrawal forms when you tell them "I see you are overwhelmed by this new tool you're learning. To solve this problem here's a new tool to learn". The near-universal sentiment I've gotten from students going from C/C++ to Rust is "Wow, this is so much nicer". YMMV.

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

#174

Post by mondoshawan » Wed, Mar 31, 2021, 5:45 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.

I can't speak to this directly because of numerous reasons, chiefly among them being that I don't get to make those decisions. Standard disclaimer follows: I rejoined in the last two years, what follows are my opinions, these opinions are my own, blah blah.

Android has never been about driving the hardware narrative -- it's always been about building a phone with mostly open contributions and driving the start of a wedge to open up the phone industry a bit. It's always been a software answer to a hardware problem, even today. Prior to Android, all we had were closed source low powered feature phones and Blackberries.

That being said, building silicon is non trivial work, and building a BLE stack and controller is even more so. Will a solid BLE stack sell phones? Hard to say how it could drive that narrative, realistically, and even harder to say if such a controller could be made cost effectively. Given Android's archetype (software solution to closed hardware), this puts such a project into a much more difficult position politically and financially.

I can't see this kind of thing having much in the way of legs in a large corp. That being said, I do think if a startup could challenge this landscape, it is a HUGE opportunity.

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

#175

Post by reader_mode » Wed, Mar 31, 2021, 5:46 PM UTC

travisgriggs wrote: post #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 c…

> Oh, and don't forget that just because it works on your Samsung, doesn't mean it works on your Moto.

And just because it works on a new Samsung doesn't mean it works on a 2 generations old one. I had to do two projects recently developing cross platform mobile apps, one had to interface with the WIFI stack - holly shit the deprecated APIs that only work on Android 10, legacy that doesn't work but is the only way to do it on Android To be fair, iOS doesn't expose a lot of that functionality to user space apps (without special certs) but I prefer that to Android where it's technically possible but practically impossible because of the insane support matrix - it just wastes time.

I'm not doing any mobile development from now on - the entire process is just riddled with busywork and working around crap APIs, people used to complain about having to support IE, mobile fragmentation is probably 10x worse.

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

#176

Post by _hzrk » Wed, Mar 31, 2021, 5:46 PM UTC

TinkersW wrote: post #148

kllrnohj wrote: post #89

Earlier quoted context omitted.

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.

Why would you need operator overloading in a low-level language? It's not like you are gonna write Jupyter notebooks with it. Zig is not meant to replace MATLAB, Python or Julia. I would use it instead to build the backbone of such a data science platform.

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

#177

Post by pjmlp » Wed, Mar 31, 2021, 5:46 PM UTC

nerpderp82 wrote: post #77

pjmlp wrote: post #51

Nice to see this. Sadly the Android team, while taking this safety steps, it keeps using unsafe C userspace for NDK APIs. Security is as good as the weakest link.

This is false and a meme that continues to stall progress. Hardening the BT stack means that accidentally crappy or adversarial devices cannot use a buggy BT stack to pop a device, from kernel mode remotely. This is a hugely welcome change. The threat model from a app using the NDK is much different than having a drive by wireless attack. Defense in depth and put focus on protocols and parsing, the rest of our stacks…

The meme that stalls progress is the myth of the perfect C developer.

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

#178

Post by mschuster91 » Wed, Mar 31, 2021, 5:47 PM UTC

signal11 wrote: post #116

cogman10 wrote: post #92

Earlier quoted context omitted.

I'd imagine lots of reasons. Apple has the hardware guys to design whatever chip they need. They also have a mountain of reserve capital (Something like $1 trillion I believe?). Further, Apple's closed ecosystem means that if you want them to sell them your hardware you have to conform to their standards. With Samsung and android, it's a different story. There are many android vendors and the people producing the Blu…

I get what you're saying, but Samsung is also huge and Bluetooth is used in lots of electronics that Samsung sells -- including laptops, tablets, smart watches, TVs... or conceivably could sell, like future IoT products. If someone senior at Samsung said to their vendor "good Bluetooth or you lose the Samsung account", that would provoke some, um, intense conversations at the vendor between sales and engineering. Inc…

> If someone senior at Samsung said to their vendor "good Bluetooth or you lose the Samsung account", that would provoke some, um, intense conversations at the vendor between sales and engineering.

The problem: There aren't that many suppliers left in the field, and Broadcom knows that their customers are pretty much locked in. The notable exception is once again Apple, they have proven that they can and will go and implement the technology on their own if their suppliers fail to meet their expectations.

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

#179

Post by dmitrygr » Wed, Mar 31, 2021, 5:47 PM UTC

dukoid wrote: post #7

mondoshawan wrote: post #2

I know the guy that heads up the team that did this work -- he and I spent 2+ years fighting Broadcom's old, god-awful bluetooth code. Our whole team used to play what-if games about replacing the thing while massive code dumps came in from vendors, making the task ever larger. Zach, if you're reading this, HUGE kudos to holding the line in replacing that, and double kudos for doing it in a verifiable, sane language!

I really hope it will fare better than NewBlue and BlueDroid... https://www.androidpolice.com/2020/09/14/the-rise-and-fall-o...

NewBlue died because I quit Google. I started that project and was its main motive force.

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

#180

Post by nindalf » Wed, Mar 31, 2021, 5:49 PM UTC

burnte wrote: post #114

mondoshawan wrote: post #2

I know the guy that heads up the team that did this work -- he and I spent 2+ years fighting Broadcom's old, god-awful bluetooth code. Our whole team used to play what-if games about replacing the thing while massive code dumps came in from vendors, making the task ever larger. Zach, if you're reading this, HUGE kudos to holding the line in replacing that, and double kudos for doing it in a verifiable, sane language!

It's almost impossible to be worse than the existing Bluewooth stack. IT's the single biggest problem I have with Google phones and it's shameful it took this long to fix.

I wouldn’t assume it’s fixed yet. Even if they’ve managed to write bug free code, you’re still at the mercy of driver supplied by the chip manufacturer.