[Kernel-packages] [Bug 1156138] Re: bcmwl-kernel-source fails to build on lowlatency kernel [FATAL: modpost: GPL-incompatible module wl.ko uses GPL-only symbol '__rcu_read_unlock']

2013-07-24 Thread Stephen Parry
OK, I have spent quite a while bashing my head against this brick wall now, trying to suss out why the lowlatency kernel build chokes, whilst the generic does not. I suspect it is heavily buried somewhere either in the compiler flags or in the deeper headers. This is what I have found so far: if

[Kernel-packages] [Bug 1156138] Re: bcmwl-kernel-source fails to build on lowlatency kernel [FATAL: modpost: GPL-incompatible module wl.ko uses GPL-only symbol '__rcu_read_unlock']

2013-07-24 Thread Stephen Parry
Dug deeper, got more answers, but also more questions: rcupdate.h is heavily conditional on PREEMPT causing __rcu_read_lock/unlock to be extern rather than inline. However, this leaves the most fundamental question of all: why are some functions OK to call from non-GPL code but others not?

[Kernel-packages] [Bug 1156138] Re: bcmwl-kernel-source fails to build on lowlatency kernel [FATAL: modpost: GPL-incompatible module wl.ko uses GPL-only symbol '__rcu_read_unlock']

2013-07-22 Thread Stephen Parry
It would help if the Broadcom's brcmsmac developers would pick up the pace a little and get something into the kernel that is stable, effective, open source and supported. I only tried switching back to iwl because brcmsmac is both deaf and drops out frequently on my BCM4313 chipset. Not to