Author, do TouchID next.
Building a Linux GPU Driver for the M4 Mac Mini in One Month
71–80 of 292 posts
Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month
#72Earlier quoted context omitted.
It’s taint. Anyone who looks at it can’t work on a real open source driver because they will have had access to information they’re not supposed to. It won’t be clean room like the stuff Alyssa did.
That’s the most abstract and esoteric argument I’ve ever heard I think
The argument is not esoteric. An Apple employee working on a reverse engineered GPU driver might (intentionally or not) incorporate internal knowledge that they are contractually obligated to keep secret or write an implementation that is too close to proprietary code they had access to, to the point that it could be argued that it is a derived work.
This sort of thing has always been a concern for projects that re-implement some existing piece of software, e.g. there were concerns early on during development of the GNU project about people contributing after having been exposed to Unix source code. Similarly, it is an ongoing concern for the Wine project[1], as well as ReactOS. The later even had a code freeze and internal audit in 2006, after allegations came forward that code had been derived from disassembled Windows binaries[2].
[1] https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guide...
Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month
#73All this work is tainted since the poster is ex-Apple[1]. There is no way Linux will take that code, since people from Apple also contribute to Linux and this creates a major conflict. There's also ongoing issues around Codex for this sort of thing, given Apple is suing OpenAI over stolen trade secrets[2]. And nobody knows whether training data in other models is similarly tainted. [1]: https://codyho.dev/documents/c…
Very sad. I really want to get Linux on newer Apple chips working flawlessly but I can understand the legal minefield about this particular work.
The only cost was a month of llm usage. If the legal questions matter to you, you or someone else should be able to spend some tokens to redo their work in a similar way. I doubt Apple will actually care much about this. But even if they do, the worst they’ll do is get the repo taken down.
It may also be legal to do the following: 1. Have an llm read all the code these people have written and produce extensive documentation. 2. Have another llm consume that documentation and write another working driver. I am not a lawyer but I think this may fall under fair use, because reverse engineering is allowed for interoperability.
Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month
#74So this is specific _only_ to M4 Mac Mini and Neo? Or will this work on any M4 SoC such as M4 Max?
Right now I'm focusing specifically on the M4 Mac Mini and Neo, I just don't own any M4 Pro or Max hardware. My guess is that most of the drivers will just work on the other platforms, but we'll have to test.
Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month
#75It's extremely impressive that they were able to make a working driver so quickly. I think this is one of the best use cases for LLMs. You don't need someone to spend years reverse engineering undocumented hardware anymore. It will interesting to see how good the driver the LLMs came up with is, and whether it can be upstreamed into the Linux kernel.
I’m sure it’s really easy when you can get help from the people who made the chip or write the Apple drivers.
Did you read the article? They didn’t get help from the people who made the chip or wrote the Apple drivers.
Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month
#76Earlier quoted context omitted.
For the kernel driver it's literally just: run the hypervisor, wait for the kick, save the UAT state, replay the whole thing, make sure the output pages change, then just follow the pointer to initdata until you've built the whole tree from scratch. LLM handles the rest.
Thanks for the post and answering here, but for someone to follow in your steps there really need to be more information: how did you handle physical hardware? Did it got stuck / frozen / whatever? How did you managed reset / etc? What is your actual step-by-step process other then just telling codex / claude code "do X"? What else had to be solved along the way? I just think one good part of Marcan's work is that th…
I detail most of the development process in part 1:
https://codyho.dev/blog/hypervisor-macbook-neo/
tl;dr you reboot the device with `macvdmtool`, you install m1n1 as the boot object, you talk to the m1n1 proxy over a python shell. I'm documenting the process as I go also (see: the blog posts, also my github repos) both so others can do it and as record of the clean room nature, but this really is just GPT go brrrrr
Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month
#77Earlier quoted context omitted.
TL;DR: 1. We want to guarantee our work is not a "derivative work" of anything Apple wrote. 2. If we look at any Apple binaries, there's no way prove that our code didn't borrow from Apple. 3. Since we didn't look at any Apple binaries, then there's no way our work can be a derivative work-- we didn't even look at their stuff.
Wouldn't using OpenAI break the cleanroom?
Why would it? Unless you think OpenAI is training on Apple’s proprietary code?
Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month
#78Earlier quoted context omitted.
I find it extremely ironic that big corp openly steals IP en masse to build their models but hackers are still concerned about using same models for their reverse engineering work. I think at this point the hacking community needs to grow some balls.
Excited to see what you contribute to open source against one of the richest and most litigious companies in the world.
Nothing. I hope those companies go bankrupt, I'm not underwriting their failure to support their customers with my time and effort.
Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month
#79All this work is tainted since the poster is ex-Apple[1]. There is no way Linux will take that code, since people from Apple also contribute to Linux and this creates a major conflict. There's also ongoing issues around Codex for this sort of thing, given Apple is suing OpenAI over stolen trade secrets[2]. And nobody knows whether training data in other models is similarly tainted. [1]: https://codyho.dev/documents/c…
Very sad. I really want to get Linux on newer Apple chips working flawlessly but I can understand the legal minefield about this particular work.
That’s fine. Linux upstream won’t take his code but you can for your own purposes.
Re: Building a Linux GPU Driver for the M4 Mac Mini in One Month
#80Earlier quoted context omitted.
I certainly dont care about hiding LLM contributions and all crazy anti-LLM policies, but I really hope author can share process completely so this can be reproduced by someone not working for Apple.
> crazy anti-LLM policies Weird how justified reasonable policies get the "crazy" label.
Asahi state as one of its goals upstreaming Apple Silicon support into Linux Kernel and kernel does not have similar anti-llm policies.
Imagine what happen if OP submit patches upstream skipping Asahi and they gonna be accepted.