On 17.12.2015 21:23, Dan Williams wrote: > On Thu, 2015-12-17 at 15:08 -0500, David Miller wrote: >> From: Dan Williams <d...@redhat.com> >> Date: Wed, 16 Dec 2015 11:03:52 -0600 >> >>> On Wed, 2015-12-16 at 17:50 +0800, Xin Long wrote: >>>> Add the support for adding expire value to routes, requested by >>>> Tom Gundersen <t...@jklm.no> for systemd-networkd, and >> NetworkManager >>>> wants it too. >>>> >>>> implement it by adding the new RTNETLINK attribute RTA_EXPIRES. >>> >>> Could you also add bits to send RTA_EXPIRES back to userspace in >> the >>> route dump in rt6_fill_node(), so that userspace can figure out >> when >>> RTA_EXPIRES is supported or not? >>> >>> (obviously having it there isn't foolproof as if there are no >> routes on >>> the system yet userspace can't figure out support, but it's better >> than >>> nothing...) >> >> That brings up an interesting issue, and I do not agree that we >> should >> publish the value for the purpose of determining if the kernel >> supports >> it or not. > > That said, userspace still needs to read back the EXPIRES attribute, if > only for iproute. The program setting RTA_EXPIRES isn't the only thing > that wants to know about the route's details. > >> We need to come up with a policy for handling unknown attributes >> because what we do now doesn't work. > > Definitely agree. > >> I'm almost positive that the right thing to do is to unilaterally >> making nlmsg_parse() error out on out-of-range attribute type >> numbers, >> and then backport that to all -stable branches. > > This works for one attribute because then userspace gets an error like > EOPNOTSUPP or something. But which attribute caused it? Does > userspace then have to retry the operation a couple times with all the > different combinations of potentially unsupported options? > > If we're going to error out on unrecognized options, I'd really like to > see some kind of netlink features bitmap or something that positively > indicates which options the kernel will accept.
Based on your mail I started to look if we can simply publish the nla_policy maps to user space, which get fed to nlmsg_parse. I am working on a rtnl_annotate function which adds this information along with a new netlink flag NLM_F_DUMP_POLICY to query those. Right now I am struggeling with nested attributes and if it is safe to move NLA_UNSPEC to the value 1 so we can determine if a specific attribute is set in the policy or not... Also nested attributes seem to be quite hairy, maybe there is no reason to inform user space about them, I don't yet know. This infrastructure should be safe to use also when features get backported. Bye, 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
