Add IPv4/IPv6 rtentry prefix accessors.

[melifaro]

Summary

Multiple consumers like ipfw, netflow or new route lookup algorithms need to get the prefix data out of struct rtentry.
Instead of providing direct access to the rtentry, create IPv4/IPv6 accessors to abstract struct rtentry internals and avoid including internal routing headers for external consumers.

While here, move struct route_nhop_data to the public header, so external customers can actually use lookup functions returning rt&nhop data.

[donner]

Do I understand correctly, that dst contains an explicit bitmask, which is assumed to be continuous?

sys/net/route.h

458–461 ↗

(On Diff #80134)

#ifdef INET

otherwise the prototype is not linkable.

462–465 ↗

(On Diff #80134)

#ifdef INET6

dito

sys/net/route/route_ctl.c

313 ↗

(On Diff #80134)

inet6_get_plen() ?

[donner]

sys/net/route/route_ctl.c

270 ↗

(On Diff #80134)

Returning the mask, not the bitcount?

313 ↗

(On Diff #80134)

inet6_get_plen() ?

This seems to be correct, the INET part is wrong, isn't it?

[melifaro]

Address comments.

[melifaro]

In D27416#612562, @lutz_donnerhacke.de wrote:

Do I understand correctly, that dst contains an explicit bitmask, which is assumed to be continuous?

Yes. Also, given we have proper multipath routing in tree, I'm going to forbid non-continuous netmasks, so we cleanup at least some parts of the legacy in 13.

[melifaro]

Add scopeid to the IPv4/IPv6 accessor functions.
Add flags/rt_nhop accessor.

[donner]

Using the accessor functions and given the fact, that only continuous netmasks are allowed (not yet), the route-prefix could be shrinked by storing the prefix length instead of the mask.
The accessor function can then return the mask from a static netmask table.

[melifaro]

In D27416#613471, @lutz_donnerhacke.de wrote:

Using the accessor functions and given the fact, that only continuous netmasks are allowed (not yet), the route-prefix could be shrinked by storing the prefix length instead of the mask.
The accessor function can then return the mask from a static netmask table.

Yes, sure. There are multiple ways of proceeding further. Prefix length can indeed be stored inside the radix mask as well, speeding up these calls. We need to be accurate with mask-only use case performance, as rtsock will use netmasks for quite a long time.
Anyway, the first step here is actually isolating access to the relevant rtentry fields.