Re: [RFC 04/12] ndisc: get rid off dev parameter in ndisc_opt_addr_space

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 25.05.2016 07:15, YOSHIFUJI Hideaki wrote:
> 
> 
> Alexander Aring wrote:
>> This patch removes the net_device parameter from ndisc_opt_addr_space
>> function. This can be useful for calling such functionality which
>> doesn't depends on dev parameter. For current existing functionality
>> which depends on dev parameter, we introduce ndisc_dev_opt_addr_space to have
>> an easy replacement for the ndisc_opt_addr_space function.
>>
>> Cc: David S. Miller <davem@xxxxxxxxxxxxx>
>> Cc: Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>
>> Cc: James Morris <jmorris@xxxxxxxxx>
>> Cc: Hideaki YOSHIFUJI <yoshfuji@xxxxxxxxxxxxxx>
>> Cc: Patrick McHardy <kaber@xxxxxxxxx>
>> Signed-off-by: Alexander Aring <aar@xxxxxxxxxxxxxx>
>> ---
>>  include/net/ndisc.h | 13 +++++++++----
>>  net/ipv6/ndisc.c    | 12 ++++++------
>>  2 files changed, 15 insertions(+), 10 deletions(-)
>>
>> diff --git a/include/net/ndisc.h b/include/net/ndisc.h
>> index 2d8edaa..dbc8d01 100644
>> --- a/include/net/ndisc.h
>> +++ b/include/net/ndisc.h
>> @@ -127,10 +127,15 @@ static inline int ndisc_addr_option_pad(unsigned short type)
>>  	}
>>  }
>>  
>> -static inline int ndisc_opt_addr_space(struct net_device *dev)
>> +static inline int ndisc_opt_addr_space(unsigned char addr_len, int pad)
>>  {
>> -	return NDISC_OPT_SPACE(dev->addr_len +
>> -			       ndisc_addr_option_pad(dev->type));
>> +	return NDISC_OPT_SPACE(addr_len + pad);
>> +}
>> +
>> +static inline int ndisc_dev_opt_addr_space(const struct net_device *dev)
>> +{
>> +	return ndisc_opt_addr_space(dev->addr_len,
>> +				    ndisc_addr_option_pad(dev->type));
>>  }
>>  
> 
> I prefer not to change existing functions such as ndisc_opt_addr_space(),
> and name new function __ndisc_opt_addr_space() etc.
> 
> Plus, my original thought (when I implement these functions) was to
> have per-net_device ndisc_opt_addr_spece(), ndisc_opt_adr_data() etc.
> 
> What do you think of that?

As I understood it 6lowpan devices need to handle both, non-compressed
and compressed options/addresses. Probably one can make them
per-interface, but a change to the arguments has still to happen.

Alex?

Thanks,
Hannes


--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux