summaryrefslogtreecommitdiffstats
path: root/libnl-nf-3.0.pc.in
diff options
context:
space:
mode:
authorThomas Haller <thaller@redhat.com>2016-06-29 11:07:30 (GMT)
committerThomas Haller <thaller@redhat.com>2016-07-08 10:02:07 (GMT)
commitcae64f81d5a3d370f232af1a6f82c2213763a26c (patch)
tree3004bf5ae8c198e20298c63897e3fc0632359bb6 /libnl-nf-3.0.pc.in
parent13dec9ba95cd61bf251345f31ed181983107d9b1 (diff)
downloadlibnl-cae64f81d5a3d370f232af1a6f82c2213763a26c.zip
libnl-cae64f81d5a3d370f232af1a6f82c2213763a26c.tar.gz
libnl-cae64f81d5a3d370f232af1a6f82c2213763a26c.tar.bz2
cache: don't decide cache operation based on NL_OBJ_DUMP in ce_flags
Objects used to be marked as NL_OBJ_DUMP in ce_flags. Then, later, the flag was evaluated to decide whether: - append/prepend the object in the hash-table (relevant for for routes) - ignore duplicate nexthops for routes during oo_update(). That becomes for example rather confusing for pickup_checkdup_cb() which marks the object as NL_OBJ_DUMP for nl_cache_add(), but not during nl_object_update() (why?). Another example where that is confusing is nl_cache_move(), which would append/prepend the object based on (obj->ce_msgflags & NLM_F_APPEND). Is that correct behavior? Maybe, maybe it doesn't matter. Either way it is confusing to have the decision whether to append/prepend the object in the hash-table 3 functions down the call stack, instead as explict argument to __cache_add(). Instead, callers must tell nl_cache_add() whether to append the flag, and they must tell nl_object_update() whether the object was received during a dump. Signed-off-by: Thomas Haller <thaller@redhat.com>
Diffstat (limited to 'libnl-nf-3.0.pc.in')
0 files changed, 0 insertions, 0 deletions