> I proposechanging the values of IFA_PERM/TENT/DEPRE/SECOND, etc,
On the other hand, to maintain compatibility with existing apps (ip command),
I can change the new values instead. So now the same ip util program will
display the correct flag values for the address and then display the remaining
flags which are the O/M flags.
I will send patch for this tomorrow.
What's about ifa_flags? There is some space there, and the things
kept there now: TENTATIVE/DEPRECATED et al. are close relatives
> > Alexey, O/M are not flags for addresses, but for interfaces.
> > > But tell me, please, what is the difference between new _address_
> > > attribute IFA_IFFLAGS and already existing address attrbute
Conceptually these are different, one for address and one for interface.
But I also
agree to your point that these can both be enclosed within one attribute
If we agree to do it in this way, then we have to change the values of
the two sets of #defines (if_flags & ifa_flags since they intersect). I
changing the values of IFA_PERM/TENT/DEPRE/SECOND, etc, for no other
than the MANAGED/OTHER flags has values copied off from the RA (bitwise
the icmpv6_nd_ra field of RA). It might make more meaning to keep 0x80
for field 'M'
which is the first bit of the field, but let me know if this is not
This does not pass through Occam's razor. Why not to give a filter to
RTM_GETROUTE? We did not implement filtering not because we do not want,
but because we (me, is more appropriate) are lazy.
OK, I can change that to give a filter. Is it OK to add the filter to
I was thinking of adding RTM_F_PREFIX, and rt6_dump_route() can pass
to rt6_fill_node() which does filtering of routes based on whether this
flag is set
or not. Did I understand you correctly here ?
Also, I am not sure that the interface should include things sort of
+ if ((addr_type & (IPV6_ADDR_LINKLOCAL | IPV6_ADDR_LOOPBACK |
+ IPV6_ADDR_MULTICAST)) != 0 ||
+ addr_type == IPV6_ADDR_ANY)
I can remove the check completely and introduce a new flag RTF_PREFIX_RT
between various route types.
Are these modifications OK ?
For kernel all they are direct routes, if the application wants to apply
some policy not formulated in terms of filters for RTM_GETROUTE, let it
to filter itself. Moreover, I used to emphasize that user of rtnetlink
should not believe to reliability of kernel filtering. It is just
measure to guarantee that a new application, which is aware of a new
attribute, will behave correctly with older kernels, which are not aware
of this attribute. Not a requirement, of course.
Anyway, if you want to apply such specific policy, you can add a flag
to rtm_flags, which would say: RTM_F_OFFICIALLY_PREFIX and base filtering
on this flag, when it is given.