diff options
author | Thomas Haller <thaller@redhat.com> | 2016-06-29 11:07:30 (GMT) |
---|---|---|
committer | Thomas Haller <thaller@redhat.com> | 2016-07-08 10:02:07 (GMT) |
commit | cae64f81d5a3d370f232af1a6f82c2213763a26c (patch) | |
tree | 3004bf5ae8c198e20298c63897e3fc0632359bb6 /libnl-nf-3.0.pc.in | |
parent | 13dec9ba95cd61bf251345f31ed181983107d9b1 (diff) | |
download | libnl-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