Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

android.googlesource.com

Post reply on HN
Print view View original

231–240 of 393 posts

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

#231

Post by yjftsjthsd-h »

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…

> 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.

What legal battles were there? Wikipedia puts Android being started in 2003 [0] and then only legal battle I recall with BSD having settled in 1994 [1].

[0] https://en.wikipedia.org/wiki/Android_version_history

[1] https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....

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

#232

Post by cultyyy123 »

ModernMech wrote: post #217
cultyyy123 wrote: post #200

Earlier quoted context omitted.

"new" and "delete" considered as bad practices. You claimed that you don't have to teach Manual Memory management in Rust so why not do the same for C++? "Rust makes all of this go away. They don't have to manage their memory manually" Both C++ and Rust has manual memory management but rarely needed. Both supports RAII where everything managed automatically.

> "new" and "delete" considered as bad practices. Depending on what kind of work you do, you may not have a choice as to whether you get to you smart pointers or not. Our students go into work with decades-old codebases littered with new and delete. They need to know what they do. > You claimed that you don't have to teach Manual Memory management in Rust so why not do the same for C++? Because there are no old rust…

I have worked with decades old codebases. I use up-to-date compiler where you get to use smart pointers and all the Modern C++ features. It's your fault if you not teach them how to upgrade the compiler. There is zero risk when compiling C++98 with C++11.

It's also student fault if he selects a company with C++98 codebase. The student shall do due diligence.

It's my advice for you to teach the Modern C++ before driving into legacy C++ sort of like how you teach History. You start what's current then drive deep under.

It builds intuition.

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

#233

Post by nerpderp82 »

est31 wrote: post #65
nerpderp82 wrote: post #62

Earlier quoted context omitted.

And it doesn't have memory safety. Zig is really fun and it is excellent for small wasm modules, but until it gets memory safety it will never be a Rust alternative.

More on the missing memory safety of Zig: https://scattered-thoughts.net/writing/how-safe-is-zig/ Discussion from 9 days ago: https://news.ycombinator.com/item?id=26537693

Thanks for the links. I donate a pittance to Zig, I really want to see where CTFE goes. If nothing else, Zig pushes the state of the art and every time a new system does, it sets the lower bound (hopefully) for the future.

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

#234

Post by kllrnohj »

reader_mode wrote: post #185
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…

> 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). I've been interested in D since the early days (back when it had two competing standard libraries) - I think you're kind of misrepresenting why D never ca…

> If someone came up with something ala D (strong C/C++ interop, fast compile times, good metaprogramming, modules, package manager) without the GC and LLVM based (so it's super portable out of the box) I'm sure it would gain traction.

D themselves did that, that's what I was referring to: https://dlang.org/spec/betterc.html

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

#235

Post by yjftsjthsd-h »

jillesvangurp wrote: post #120
nahuel0x wrote: post #61

Fuchsia network stack is also being rewritten from Go to Rust [1] and it follows a functional core/imperative shell pattern, something very unusual in network stacks [2]: [1] https://fuchsia.dev/fuchsia-src/contribute/contributing_to_n... [2] https://cs.opensource.google/fuchsia/fuchsia/+/master:src/co...

Interesting; makes you wonder about the potential for code sharing between that and Android or even linux as well. The Linux kernel developers are open to allowing some Rust usage for things like drivers at this point. So the time seems right for this kind of thing. I guess there is also some decent code from e.g. redox os that might be adapted. Licensing (MIT) should not be an obstacle for this as far as I understan…

> I imagine e.g. Samsung might have some hesitations about being even more dependent on Google as a supplier.

Does it make them more dependent? Google is effectively the only upstream for Android, and Fuchsia is open source, so it seems like it should be the same?

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

#236

Post by ansible »

parwan98 wrote: post #29
radicaldreamer wrote: post #11

Is this shipping in Android S?

It's shipped in Android 11, but in disabled state. On Pixel, developer options, bluetooth, enable "Gabeldorsh" if you want to live on the bleeding edge.

Huh, I just poked around and saw that option on my Pixel 3a.

On the one hand, it might be interesting to try it. On the other hand, at least with the one BT device I regularly use, the current stack works flawlessly...

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

#237

Post by PragmaticPulp »

Wohlf wrote: post #223
PragmaticPulp wrote: post #184

Earlier quoted context omitted.

Can you shed some light on what we’re actually looking at here? I see some Rust but most of the actual BT stack looks to be C++ code. Is the HN headline accurate?

Did you miss this on the main page? > We are missing Rust support in our GN toolchain so we currently build the Rust libraries as a staticlib and link in C++.

Right, but the headline suggests the BlueTooth stack is being rewritten in Rust while the code seems to suggest that the stack is in C++ still. There isn’t much Rust code in the directory relative to all of the C++

4K lines of Rust is not a BlueTooth stack.

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

#238

Post by realityking »

eecc wrote: post #218
parwan98 wrote: post #55

Earlier quoted context omitted.

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…

So given these data points, isn’t it reasonable for Apple to refuse to play along this broken tune and just roll out their own dialect of a wireless protocol? Why, if not in the name of scarcely affirmed “standards”, drag suppliers through an endless contractual game, when you can direct your own capacity toward the quality standards that fit you?

I don’t follow the leap. The grandparent’s point was about the quality and terrible lack of long term support of Broadcom chips. How does that translate to issues of the standard itself?

Nobody would complaining about Apple creating their own radio chips (which they seem to plan for 5G/6G). Apple creating their own standard protocols is an issue though.

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

#239

Post by kllrnohj »

adkadskhj wrote: post #151
johnnycerberus wrote: post #134

Earlier quoted context omitted.

I share your view partially. As you said, code generation is difficult and it can get messy pretty fast, but this is the beauty of Zig, you have these features tightly packed, there is a capped number of ways for doing things. In Zig you learn how to use the wand properly, instead of being distracted by trying different sizes and colors of wands. While many languages focus on the breadth of ways of doing things, Zig…

Sounds a lot like Go. For me, that was a huge problem with Go. I can only speak for Go, not Zig at all, but not giving me the "wand colors" meant that when i still needed colors to solve my problems, i had to invent them myself. .. okay this analogy breaks down there, but yea. The need for basic things like iterators, enums, and sometimes even generics didn't go away in Go. They didn't stop being extremely useful pat…

> So what do you do with something that is still useful, possibly needed, but missing? You reinvent it.

Yup, see for example java.lang.Comparable which is basically just the standard library going "yeah the language screwed up, here's your operator overloading"

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

#240

Post by adwn »

johnnycerberus wrote: post #195
adwn wrote: post #190

Earlier quoted context omitted.

> Why would you need operator overloading in a low-level language? Have you ever heard of matrices and vectors? You need them in a lot of DSP (digital signal processing) applications, like audio and video filters, or in 3D graphics. Being able to write x = m * y instead of x = m.vector_mult(y) makes life so much more pleasant.

In Zig you write libraries that should be explicit and maintainable.

    x = m * y
is even more explicit than

    x = m.vector_mult(y)
because the * operator is side-effect free by convention, while a method like vector_mult() might or might not be mutating (i.e., it could work like the *= assignment operator).
Post reply on HN