Remembering Larry Finger, who made Linux wireless work
arstechnica.com
arstechnica.com
In the early 00s I bought a laptop that had an RTL 8188 CE card in it that ran awful under Linux. I forked his driver and made a number of changes to it and eventually got my wifi working really well (by doing things that could never be upstreamed due to legal/regulatory restrictions). Over the years I rebased often and reviewed the changes, and learned a lot from watching his code. It took a bit of getting used to, but a certain amount of beauty and appreciation emerged. One thing was very clear: This man was doing a lot of the work to keep the ship together. Even just keeping the driver compilable with each kernel release often took some non-trivial refactoring, which he did reliably and well.
Larry, you will be missed my friend. RIP.
If you are waiting to reach out to somebody, don't wait too long or it may suddenly be too late. The years can slip by in a flash.
I realise that the kernel contributors themselves are mostly volunteers and as such can just do what they want, and writers of non-upstreamed drivers will need to get used to chasing trunk, but to me this sort of thing seems like a waste of human talent. once something works, it should never not work again. it seems to me that despite all the layers of cruft that we've accumulated over the decades haven't really helped much with this, in fact they probably mean more work just to stay still.
I've also fantasised about the same thing in application programming languages - e.g. the way racket runs loads of different dialects, you could also have versioning for different things running at the same time.
There are exceptions to every rule, re-writing old software because it’s old needs a rare exception indeed.
The Linux kernel is a good example. Should we rewrite it? No of course not. So was your point about code that hasn’t been maintained in a decade? Sure, maybe then. But I can’t square “code that hasn’t been touched in a decade” with “still in active use today”
Conway’s Law[1]:
> Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
In his famous lecture [2], Casey Muratori makes the case that Conway’s Law applies over time too, meaning there is not a single organization, but multiple versions of the organization over time, and all of them end up adding more design (decisions) to the product. The best example, which he gives, is the 5 different UIs to change the sound level in Windows.
Rewrites to old (10 years old as I said) software reset the age of the software to zero and very often drastically simplify both the design and the codebase. I’m not telling you to rewrite your 3 yo product.
This is the major flaw in your argument. This just isn’t true.
Software is defined by its interfaces, and unlike userspace APIs, this guarantee does not apply to internal kernel APIs. The ability to update the latter is what enables the former. Inability to update internal implementation details inevitably leads to ossification and obsolescence of the whole system. Linus Torvalds spoke about this recently in the context of new Rust code in the kernel.
No, in practice I think it leads to growing complexity, because the system then adds additional APIs (e.g., v1, v2, v3, etc.) to support new features, but has to continue to maintain the old APIs for backwards compatibility, leading to lots of extra code and a huge maintenance burden.
Politics. Offering a stable-ish internal API would instantly lead to hardware vendors shipping closed source drivers for Linux.
Currently, you have to be the size of NVIDIA or AMD to be able to afford a closed source driver, it's simply a huge work to keep up with the constant improvements in the Linux kernel.
Embedded/mobile projects don't tend to use bleeding-edge kernels and stuck on one version regardless of closed source modules anyway.
[1] https://arstechnica.com/information-technology/2020/03/the-e...
These guarantees are not that strong, unfortunately. For example, API between kernel-mode and user-mode halves of the GPU driver is unstable. To have 3D accelerated graphics on RK3288 you gonna need either libmali-midgard-t76x-r14p0-r0p0-gbm.so or libmali-midgard-t76x-r14p0-r1p0-gbm.so userspace library, depending on a minor hardware revision of that RK3288.
It may be that in the hypothetical absence of a salary giving them an excuse, many of these individuals may also choose to volunteer, but it's wrong to call contributors "mostly volunteers" when that's their day job. Changesets from those known to be spending their own time on contributing are a relatively small fraction of the changes.
These things are illegal for a reason.
https://arstechnica.com/gadgets/2024/06/larry-finger-linux-w...
I remember cursing ndis wrappers and Broadcom wifi ecosystem a long time ago, Larry helped fixed that, and mentored many others along the way.
quote from the arstechnica article "In a 2023 Quora response to someone asking if someone without "any formal training in computer science" can "contribute something substantial" to Linux, Finger writes, "I think that I have." Finger links to the stats for the 6.4 kernel, showing 172,346 lines of his code in it, roughly 0.5% of the total."
What do I think about? Why the hell did he volunteer his post work hours trying to do this menial job hardware thing. Did he not have a family or something? He did. And today they lost him.
I wondered the same, imagining some 40-something FTE frustrated with bureaucratic work projects and with a couple young kids. Guess what, this guy passed at 84! Which means the driver work happened in his 60+ years. I will be lucky if I can remember my name at that age. :-)
> so Finger helped reverse-engineer the necessary specs by manually dumping and reading hardware registers
I really wanted to leave this quote here for all to see. The badassery of this act should not be underestimated.
I've done a little bit of work along those lines. Reverse engineering my laptop's features, writing my own free software to drive them from inside Linux, emailing the manufacturer asking for documentation and receiving user help pages. It was mostly USB stuff, the most well documented interface imaginable, and it was still hard. I simply cannot fathom how he reverse engineered this Wi-Fi stuff. That's just a huge inspiration for me, I hope I can get near his level some day.
Thank you so much for your work and RIP.
I'm really looking forward to seeing a brave soul show up to try and reverse engineer those 50 thousand hardware initialization memory accesses. That sort of thing is just incredibly difficult. I'd really enjoy reading about that too.
In my case I intercepted USB communications with wireshark and tried to make sense of the packets. I'd use the proprietary manufacturer app, capture what got sent over USB and correlate the packets to hardware behavior. Mapped out all the functions that way. There were hundreds of them but mercifully most of those were the same command but with different parameters. The result was this totally magical software which sends buffers containing seemingly random numbers to the hardware and somehow that makes things happen.
/* Clevo Control Center
* Effects
* Wireshark Leftover Capture Data
*
* 0 Wave cc00040000007f
* 1 Breathe cc0a000000007f
* 2 Scan cc000a0000007f
* 3 Blink cc0b000000007f
* 4 Random cc000900000000
* 5 Ripple cc070000000000
* 6 Snake cc000b00000053
*
* There seems to be no pattern to it. Does the value of the last byte matter?
* My keyboard apparently doesn't support the ripple effect,
* even though it is present in the Clevo Control Center interface.
*/
That article has some follow-ups which should be linked below it or can be googled. IIRC the author uses some clever shortcuts to speed up the work.
/years/decades/s
This has some serious GNU-Pratchett vibes - http://www.gnuterrypratchett.com and nice to see
Please don't get me started on suspend-mode low energy consumption. It hasn't been true for any device I've owned. Perhaps yours, fine, but my anecdotal experiences and acquaintances' show you're in a minority.
The inclusion of the fish in the tagline made me smile. There’s an innocence to the sentence that captures the image really well.
.
RIP