The devices ship with a kernel that can use them. Is there anything we can do to make it easier to extract whatever device tree or other information from the compiled kernel it ships with, so it can be used with any other Linux kernel?
You can use the downstream kernel directly via Droidian (a Mobian-derived GSI image). But otherwise the downstream kernels and device trees tend to be useless from an upstream development perspective - too hacked together and not maintainable in practice. Your proposed approach can be used however to extract existing firmware blobs (that will run unchanged no matter what the booting OS), and Mobian is pursuing that approach.
What stops someone from decompiling the closed source driver into barely legible "source code" and then grafting that onto a generic kernel so it can run on the device? It wouldn't be pretty but it would probably be a faster way to get running on the device than having to write a complete reverse-engineered driver from scratch before you can even boot, and then you have a starting point for writing an open source driver that doesn't suck as much.
Could some change be made to the kernel to make that process easier? Do we need better tools to make it more practical?
If you look at a decompiled code and are influenced in how you write your code by the decompiled code, this is probably a "derivative work" of the original program and not just "reverse engineering" from the way that the computer program works. Copyright for software protects the decompiled code that is written, as a literary work, and anything derived from that decompiled code is also protected..
[clean-room reverse engineering] One group examines the source to write the specs and rundown. Another to make the code again, with no people from group 1 taking to them but for the spec sheet
> do we need better tools to make it more practical?
Good question, perhaps others can comment. The challenge is likely economics, not tooling.
This is GPL code so decompiling isn't necessary or the problem.
Accepting over the wall low quality code and having a submitter for it who may know nothing about it makes it difficult to work any of this low quality code into the mainline kernel via its resource starved processes.
Possible, but sometimes vendor code isn't acceptable for upstream, even when public. Some vendors ship binaries with EULA restrictions to customers, who choose not to exercise their GPL rights.
A modern approach to working around the GPL is to move functions from open drivers to closed firmware.
