On 5/16/2023 10:55 AM, Ferruh Yigit wrote:
> On 5/16/2023 2:28 AM, Stephen Hemminger wrote:
>> On Tue, 16 May 2023 00:35:56 +0100
>> Ferruh Yigit <ferruh.yi...@amd.com> wrote:
>>
>>> Yes only some scripts and possible applications that hotplug tap
>>> interface with hardcoded parameters may impacted, don't know how big is
>>> this amount but this ends up breaking something that was working before
>>> upgrading DPDK for them.
>>>
>>> And I believe the motivation is weak to break the behavior.
>>>
>>> Won't it be better to update 'rte_ether_unformat_addr()' to accept more
>>> flexible syntax, and use it? Is there any disadvantage of this approach?
>>
>> It is already more flexible than the standard ether_aton().
>
> I mean to accept single chars, as 'tap' currently does, like "a:a:a:a:a:a".
>
> Agree that impact of tap change is small, but if we can eliminate it
> completely without any side affect, why not?
>
>
> As accepting single char will be expanding 'rte_ether_unformat_addr()'
> capability, it will be backward compatible, am I missing anything?
>
Hi David,
If API update is not planned, what do you think to just solve the build
error without changing functionality with a change something like below:
```
- (strlen(mac_byte) == strspn(mac_byte,
- ETH_TAP_CMP_MAC_FMT))) {
+ (strlen(mac_byte) == strspn(mac_byte, ETH_TAP_CMP_MAC_FMT)) &&
+ index < RTE_ETHER_ADDR_LEN) {
```
