On Thu, 2013-01-31 at 17:03 +0100, Florian Fainelli wrote: > We can't do anything serious out of this, the broadcom xDSL drivers > make > use of a heavily modified struct sk_buff which is subject to changes > from one kernel version to another. > -- > Florian > This was always the problem, and short of the type of monumental effort it would take to rewrite them to use linux-atm that b43 took, the only thing that _could_ be done for the time being would be creating some sort of abstraction layer around Broadcom's object code. I do not know in what different forms the xDSL drivers appeared in other tarballs, but I'm guessing some of them might be less or more suitable for this than others. Since Broadcom reimplements huge sections of the kernel themselves, I would expect they make rather minimal use of kernel ABI's, and maintaining a backward-compatibility layer to accommodate a single binary blob (as was done for one for the 2.6.11 kernel for a while) is not feasible, but as you can see, we keep seeing newer tarballs with blobs for newer kernel versions, so complete breakdowns in ABI compatibility are never permanent.
I understand the decision not to put forth the effort to do this, and I understand that all efforts to negotiate a compromise with Broadcom like the one reached for wifi have failed, but what would it take to create more leverage? I know that at some point, the French ISP Neuf wanted to broker some sort of agreement which also failed, proving that ISP's do not have such standing with Broadcom, so which device manufacturer could best be approached to assist? _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
