Re: [PATCH net-next 01/10] net: etherdevice: add address inherit helper

["Bjørn Mork" <bjorn@mork.no>]

David Miller <davem@davemloft.net> writes:

> From: Bjørn Mork <bjorn@mork.no>
> Date: Sat, 24 Aug 2013 00:28:55 +0200
>
>> Stephen Hemminger <stephen@networkplumber.org> writes:
>>> On Fri, 23 Aug 2013 11:35:04 +0200
>>> Bjørn Mork <bjorn@mork.no> wrote:
>>>
>>>>  /**
>>>> + * eth_hw_addr_inherit - Copy dev_addr from another net_device
>>>> + * @dst: pointer to net_device to copy dev_addr to
>>>> + * @src: pointer to net_device to copy dev_addr from
>>>> + *
>>>> + * Copy the Ethernet address from one net_device to another along with
>>>> + * the addr_assign_type.
>>>> + */
>>>> +static inline int eth_hw_addr_inherit(struct net_device *dst,
>>>> +				      struct net_device *src)
>>>> +{
>>>> +	if (dst->addr_len != src->addr_len)
>>>> +		return -EINVAL;
>>>> +
>>>> +	dst->addr_assign_type = src->addr_assign_type;
>>>> +	memcpy(dst->dev_addr, src->dev_addr, dst->addr_len);
>>>> +	return 0;
>>>> +}
>>>> +
>>>
>>> Since all the other code in this file assumes addr_len == ETH_ALEN
>>> why does this code need to handle variable addresses. Trivial but
>>> then the memcpy is fixed size and can be optimized.
>> 
>> Didn't know that. I'll make that change in the next version.  Not that
>> optimization matters much here, but consistency is always good.
>
> You can bug check that addr_len ETH_ALEN if you want.

I don't think that is necessary.  

> I realize that some drivers don't initialize it by this call point but
> that is arguably a bug.

Yes.  But I don't believe another test is going to make those drivers
work, so it's better to just drop it.


Bjørn