在 2023/1/19 22:35, Thomas Monjalon 写道:
19/01/2023 11:31, lihuisong (C):
在 2023/1/18 22:12, Thomas Monjalon 写道:
11/01/2023 11:46, Ferruh Yigit:
On 1/11/2023 10:27 AM, Ferruh Yigit wrote:
On 1/11/2023 12:53 AM, lihuisong (C) wrote:
在 2023/1/11 0:51, Ferruh Yigit 写道:
Hi Huisong,
I haven't checked the patch in detail yet, but I can see it gives some
ABI compatibility warnings, is this expected:
This is to be expected. Because we insert a device state,
RTE_ETH_DEV_ALLOCATED,
before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
We may have to announce it. What do you think?
If there is an actual ABI break, it can't go in this release, need to
wait LTS release and yes needs deprecation notice in advance.
But not all enum value change warnings are real break, need to
investigate all warnings one by one.
Need to investigate if old application & new dpdk library may cause any
unexpected behavior for application.
OR, appending new enum item, `RTE_ETH_DEV_ALLOCATED`, to the end of the
enum solves the issue, although logically it won't look nice.
Perhaps order can be fixed in next LTS, to have more logical order, but
not quite sure if order worth the disturbance may cause in application.
It is a state with a logical order, so it would be nice to be able to do
if (state > RTE_ETH_DEV_ALLOCATED)
but given there is RTE_ETH_DEV_REMOVED later in the enum, not sure it is useful.
The device state is internel. Applications should not access it
directly, right?
Right
Currently, ethdev layer or PMD use it by enum value instead of the way like
'state > RTE_ETH_DEV_ALLOCATED'.
Right
But, I encapsulated an API, rte_eth_dev_is_used(), for ethdev or PMD to
call.
I'm not sure if it can help to eliminate our concerns.
Yes I think it's OK.
ok, I will fix it based on our discussion.
.
