On 2013-11-02 08:59, James Hilliard wrote: > Well, maybe they didn't create the shared code because of the GPL but > they can't link a binary directly to a GPL component, only a LGPL > component I think or something like that. I've object dumped and ran > decompilers on the broadcom-wl object files and I don't see anything > statically linked or any indication of anything that would be specific > to a kernel version You won't see the parts that matter in whatever tools you used to pick apart the binary. When compiling, the code includes header files from the kernel, which contain data structures, some of the most important ones being sk_buff and net_device. Stuff like that doesn't show up as symbols, and you won't find it by name in a disassembler. If you take a look at the data structures in the header files in a kernel tree, you might notice, that they even change depending on the kernel configuration. This makes attempts to reuse the prebuilt .ko file futile.
> I see plenty of needed symbols though, but those > all appear to be available to build into the kernel. > I don't see a > reason why wl_linux.c can't be compiled from source > http://sourceforge.net/projects/routertesting/files/ea6900%20patches/wl_linux.c/download > , its not like its closed source as far as I can tell, is that the only > thing preventing us from using these tarball drivers? Did you actually look at that file? This is not even driver code. > Relocatable means > its not tied to any specific memory addresses right and that any memory > address are referenced only internally? All the decompilers I used > indicated the drivers were relocatable ELF's and I didn't see any > external memory addresses referenced from any functions. Memory addresses aren't the only thing that matter, there are other ABI issues, e.g. the one I described above. - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
