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, 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? 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.
On Sat, Nov 2, 2013 at 2:05 AM, Felix Fietkau <n...@openwrt.org> wrote: > On 2013-11-02 00:30, James Hilliard wrote: > > It's a very confusing way of building a package, but the reason seems to > > come down to how the GPL works. The GPL prohibits statically linking any > > closed source packages into the kernel, that however is how drivers are > > often built. Broadcom came up with another way that gets around the > > problem by creating the hnd shared libraries that allow them to > > customize the way the driver interacts with the kernel while at this > > same time allowing them to legally build a closed source relocatable > > driver that links the open source hnd components. > I think you're misunderstanding the purpose of the shared code. It was > not created because of GPL issues at all. It's an OS abstraction layer > that they use to port their drivers to different operating systems. The > portability only works on a *source* level. Compiled binaries are still > highly kernel version specific (at least in the wl_linux.o parts). > > > The current way > > openwrt builds the broadcom-wl seems to quite a bit different than > > normal, it appears that rather than building hnd components into the > > kernel hnd was turned into an abstraction layer of some sort that > > provides an interface layer for the driver without making major kernel > > changes. > It wasn't 'turned into an abstraction layer'. The code was simply moved > someplace else. This was done because the loads of crappy code were only > needed for broadcom-wl and nothing else. > The part that allows broadcom-wl to be version independent is that all > kernel ABI dependent files are provided with source code. > > > The issue with this seems to be that maintaining the driver > > with this method is very difficult since broadcom does not release > > drivers that support this method of integration. IMO the easiest and > > most maintainable way of using the broadcom-wl driver is to patch the > > kernel at compliation with the hnd shared libraries if the wl driver is > > selected for installation. > That only solves the easiest problem of all (unresolved symbols). You > still need wl_linux.c to be compiled from source. > > > The patches I have are the patches broadcom > > uses to add hnd to a stock kernel as well as other platform > > modifications. I could be wrong about some of this but there should be a > > way to get this driver working since it is relocatable. > I think you're confused about what the word 'relocatable' means. > > - Felix > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
