[dpdk-dev] [PATCH 1/2] config/arm: fix Hisilicon kunpeng920 SoC build

[oulijun]

在 2021/3/1 18:46, Juraj Linkeš 写道:
> 
> 
>> -----Original Message-----
>> From: Thomas Monjalon <thomas at monjalon.net>
>> Sent: Wednesday, February 24, 2021 1:10 PM
>> To: Juraj Linkeš <juraj.linkes at pantheon.tech>
>> Cc: oulijun <oulijun at huawei.com>; ferruh.yigit at intel.com; dev at dpdk.org;
>> linuxarm at openeuler.org
>> Subject: Re: [dpdk-dev] [PATCH 1/2] config/arm: fix Hisilicon kunpeng920 SoC
>> build
>>
>> 24/02/2021 12:55, Juraj Linkeš:
>>> From: dev <dev-bounces at dpdk.org> On Behalf Of Thomas Monjalon
>>>> 24/02/2021 02:34, oulijun:
>>>>>
>>>>> 在 2021/2/10 17:41, Thomas Monjalon 写道:
>>>>>> 03/02/2021 13:46, Lijun Ou:
>>>>>>> From: Chengchang Tang <tangchengchang at huawei.com>
>>>>>>>
>>>>>>> Because of the '9ca2f16' have merged, the current hns3 pmd
>>>>>>> driver can not be directly complied on the kunpeng920 server board.
>>>>>>> Therefore, we need to fix the meson build.
>>>>>>> Besides, add kunpeng 920 SoC meson cross compile target.
>>>>>>>
>>>>>>> Fixes: 9ca2f16faa7f ("config/arm: isolate generic build")
>>>>>>
>>>>>> Why do you think this patch is fixing the one above?
>>>>>> It looks just a new config, not a fix. Am I missing something?
>>>>>>
>>>>> I'm sorry to see you so late. In the meantime, we are celebrating
>>>>> the Spring Festival. This patch fixes the problem. If the patch is
>>>>> not added, the latest version cannot be directly compiled on the
>>>>> Kunpeng
>>>>> 930 server board.In addition, the cross compilation configuration file is
>> added.
>>>>
>>>> Please can you explain what was removed which breaks your compilation?
>>>>
>>>
>>> I can explain what's changed and why we changed it.
>>>
>>> The previous behavior was that when an uknown implementer was found
>> (when we're building on an uknown build machine) we fell back to a generic
>> build.
>>> The current behavior is we raise an error when building on an unknown build
>> machine and inform the user about the generic build (there's an error in the
>> message, it should be -Dmachine=default instead of -Dmachine=generic). Lijun
>> came across this scenario, so he wants to add an implementer, but it is not a fix,
>> rather an addition that we wanted to encourage when we changed the
>> behavior. The change in behavior also has an additional benefit in that it notifies
>> the user that meson is not doing a tailored build for the build machine and the
>> only permissible build is the generic one.
>>
>> There were already many fixes for that rework.
>> Please check if there are other missing updates.
>>
> 
> This is actually the first mistake that my testing missed. I tested that the message is properly emitted, but I didn't test the message after we extracted the default->generic rename patch. As a side note, we could address this issue with http://patches.dpdk.org/project/dpdk/patch/1613657555-17683-1-git-send-email-juraj.linkes@pantheon.tech/ - then we can leave the message in place as is (with -Dmachine=generic).
> 
> I went through all of the patches again but I didn't find anything that needs addressing.
> 
> As far as I'm aware, there were two other fixes for the series. One was a failure of communication (the native margs fix - I implemented what we thought we agreed on) and the other is not really a fix, just the addition of one implementer configuration (I removed the implementer because we didn't have its configuration). The clang cross-compile fixes are related, but those are the problem with that series, not the rework series.
> 
Hi,
   the patch 
http://patches.dpdk.org/project/dpdk/patch/1613657555-17683-1-git-send-email-juraj.linkes@pantheon.tech/
will this patch be incorporated? We have realized this problem and fixed 
it in the internal version.
>>
>>
>