[OpenWrt-Devel] [PATCH] base-files: move kmodloader below uci_apply_defaults

[Zefir Kurtisi]

On 2/25/19 7:13 PM, Bjørn Mork wrote:
> Zefir Kurtisi <zefir.kurtisi at neratec.com> writes:
> 
>> On 2/25/19 3:23 PM, Piotr Dymacz wrote:
>>> Hello Zefir,
>>>
>>> On 25.02.2019 15:08, Zefir Kurtisi wrote:
>>>> re-post, missed CC
>>>>
>>>> On 2/25/19 2:52 PM, Bjørn Mork wrote:
>>>>> Zefir Kurtisi <zefir.kurtisi at neratec.com> writes:
>>>>>
>>>>>> Some kernel modules have colliding symbol naming
>>>>>
>>>>> This is not true.
>>>>>
>>>>>
>>>>> Bjørn
>>>>>
>>>>
>>>> Hm, I gave an example in the commit message and if it helps, I can post the
>>>> related log-output to prove my claim. But you might mean something else?
>>>
>>> But the 'qcawifi' is not part of the kernel and OpenWrt project.
>>>
>> The QSDK [1] is based on OpenWRT and is open source. During development of ath10k
>> (and earlier ath9k), qca-wifi code has been ported to the other side (and maybe
>> vice-versa). That's why some exported kernel symbols in the drivers overlap.
>>
>> If the argument to not consider the proposed change is based on politics (i.e. 'it
>> is for something not being part of OpenWRT core'), I'm fine dropping it and
>> keeping the change privately. But I'm pretty sure there are use cases where it
>> would be helpful to disable kernel-modules in the uci-default processing - as an
>> example of fully supported by OpenWRT, think of selecting mainline or
>> Candelatech's ath10k driver based on installed HW.
> 
> Sorry, I have no policy issues or anything like that.  I just pointed
> out that your commit message started with a false statement.  And I am
> sorry, but I tend to read such messages like a set of ANDed booleans, so
> I usually stop at the first false statement.  Nothing following it can
> make the message as a whole true.
> 
> OK?
> 
Hi Bjørn,

sure, that's just the correct way to go and I fully agree that reading behind the
&& in 'if (0 && ...)' is a waste of time ;)

I already agreed Piotr's argumentation that such a core change might introduce
regressions and will therefore keep the commit in our private tree.

But to clarify your point: it is possible to have kernel modules with colliding
symbols. Just add two drivers which export 'foo()', both will be built and
installed, but loading the second will fail. At least this is my observation,
there are no mechanisms in place that prevent kernel symbols to be exported more
than once.


Cheers,
Zefir


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel