Unlike memcpy() and other copy functions, rte_ether_addr_copy() takes the destination as the second parameter.
Not following well established conventions adds a high risk of causing bugs in the applications/libraries/drivers; it is likely that developers expect copy() functions to take parameters in the usual memcpy() order, and pass the parameters to rte_ether_addr_copy() in that order instead of the reverse order expected by rte_ether_addr_copy(). How can we fix this? One way would be to introduce a new copy function and mark the old function deprecated (due to risk of bugs). Does the community support such a change? And what would be a good name for the new function? Any other ideas for fixing it? Med venlig hilsen / Kind regards, -Morten Brørup
