- Add rib_<add|del|change>_route() functions to manipulate the routing table.
The main driver for the change is the need to improve notification mechanism.
Currently callers guess the operation data based on the rtentry structure returned in case of successful operation result. There are two problems with this appoach. First is that it doesn't provide enough information for the upcoming multipath changes, where rtentry refers to a new nexthop group, and there is no way of guessing which paths were added during the change. Second is that some rtentry fields can change during notification, and protecting from it by requiring customers to unlock rtentry is not desired.
Additionally, as most of the consumers do know which operation they are going to execute in advance, making explicit add/change/del versions of the functions makes sense, especially given the functions don't share a lot of code.
With that in mind, introduce rib_cmd_info notification structure and rib_<add|del|change>_route() functions, with mandatory rib_cmd_info pointer. It will be used in upcoming generalized notifications.
struct rtentry *rt; error = rtequest1_fib(RTM_ADD, info, &rt, fibnum); # report on rt and rt->rt_nhop
struct rib_cmd_info {
uint8_t rc_cmd; /* RTM_ADD|RTM_DEL|RTM_CHANGE */
uint8_t spare[3];
uint32_t rc_nh_weight; /* new nhop weight */
struct rtentry *rc_rt; /* Target entry */
struct nhop_object *rc_nh_old; /* Old nhop OR mpath */
struct nhop_object *rc_nh_new; /* New nhop OR mpath */
} rc;
error = rib_add_route(fibnum, info, &rc);
# report on rc- Move definitions of the new functions and some other functions/structures used for the routing table manipulation to a separate header file, net/route/route_ctl.h. net/route.h is a frequently used file included in ~140 places in kernel, and 90% of the users don't need these definitions.