Hi,
On 14.12.2015 12:48, Xin Long wrote:
>>
>> This is the wrong way to do this.
>>
>> Currently we only ever dump rta_cacheinfo values to the user.
>>
>> If we use it to set things, we have to completely consider every
>> member of that structure as potentially having meaning either
>> intended by the user or choosen by us in the future.
>>
>> Therefore it is a poor choice to start using for specifying the
>> expires value, and some other mechanism such as a new RTNETLINK
>> attribute, should be used for this.
>
> we did it like this to avoid adding the new RTNETLINK attribute.
> now I got your meaning, and rta_cacheinfo seems to be designed
> for dumping info, not for seting info. i guess you hope we do it like:
>
> + if (tb[RTA_EXPIRES]) {
> + unsigned long timeout =
> addrconf_timeout_fixup(nla_get_u32(tb[RTA_EXPIRES]), HZ);
> +
> + if (addrconf_finite_timeout(timeout)) {
> + cfg->fc_expires = jiffies_to_clock_t(timeout * HZ);
> + cfg->fc_flags |= RTF_EXPIRES;
> + }
> + }
>
> hi Hannes, we seem to go back here again, what do you think ?
Albeit I had the same idea and wanted to introduce a new netlink
attribute, I decided to recommend this patch. It aligns with the code we
already have for adding and listing ipv4 and ipv6 addresses
(ifa_cacheinfo) and reporting routing changes for ipv4 and ipv6
(rta_cacheinfo).
We can easily switch to new attributes. Should we introduce a new
interface for this?
Thanks,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
