batadv_mcas..._scrub_dests(9)
π¦ batadv_mcast_forw_scrub_dests β scrub destinations in a tracker TVLV
okay so this is a page from the Kernel API Manual, and bestie, it's giving "tiny function, huge job" energy. the name up top is batadv_mcast_forw_scrub_dests(9) β say that five times fast, i dare you π
β¨ SYNOPSIS β¨
void batadv_mcast_forw_scrub_dests (struct batadv_priv *bat_priv ,
struct batadv_neigh_node *comp_neigh , u8 *dest , u8 *next_dest , u16
num_dests );
like, five args, zero return value, all business π
πΈ ARGUMENTS πΈ
bat_privβ the bat priv holding all the mesh interface info. it's the main character, it knows everything πcomp_neighβ the next hop neighbor we're scrubbing + collecting destinations for. our fave (for now) π«Άdestβ start MAC entry in the original skb's tracker TVLV. where the og list begins β¨next_destβ start MAC entry in the to be sent skb's tracker TVLV. the copy's starting point πnum_destsβ how many remaining destination MAC entries we're iterating over. the countdown, basically β
π₯ DESCRIPTION π₯
so what it does: it sorts destination entries into either the original batman-adv multicast packet or the skb (copy) that's about to be sent to comp_neigh next. two piles, one function, no cap π
here's the vibe. we're prepping the next batman-adv multicast packet skb β the one that's gonna be (unicast) transmitted to the given neighbor node. in preparation for that, the function tries to collect all the originator MAC addresses that have the given neighbor node as their next hop, in the to-be-transmitted skb (copy) β the one next_dest points into. π§
and then the actual scrubbing, which is lowkey the whole plot:
- it zeros all destination entries in
next_destthat do not havecomp_neighas their next hop π«§ - and it zeros all destination entries in the original skb that would have
comp_neighas their next hop β so we avoid redundant transmissions and duplicated payload later. iconic efficiency behavior, honestly π
ngl the zeroing is the whole point: one list keeps who's actually going where, the other gets emptied out so nobody gets the same payload twice π
π SEE ALSO π
kernel file ./net/batman-adv/multicast_forw.c β that's the home base, go say hi π
and the whole friend group, fr fr:
batadv_mcast_forw_skb_push(9), batadv_mcast_forw_push_padding(9), batadv_mcast_forw_push_est_padding(9), batadv_mcast_forw_orig_entry(9), batadv_mcast_forw_push_dest(9), batadv_mcast_forw_push_dests_list(9), batadv_mcast_forw_push_tt(9), batadv_mcast_forw_push_want_all(9), batadv_mcast_forw_push_want_rtr(9), batadv_mcast_forw_scrape(9), batadv_mcast_forw_push_scrape_padding(9), batadv_mcast_forw_push_insert_padding(9), batadv_mcast_forw_push_adjust_padding(9), batadv_mcast_forw_push_dests(9), batadv_mcast_forw_push_tracker(9), batadv_mcast_forw_push_tvlvs(9), batadv_mcast_forw_push_hdr(9), batadv_mcast_forw_shrink_fill(9), batadv_mcast_forw_shrink_pack_dests(9), batadv_mcast_forw_shrink_align_offset(9), batadv_mcast_forw_shrink_update_headers(9), batadv_mcast_forw_shrink_move_headers(9), batadv_mcast_forw_shrink_tracker(9), batadv_mcast_forw_packet(9), batadv_mcast_forw_tracker_tvlv_handler(9), batadv_mcast_forw_packet_hdrlen(9), batadv_mcast_forw_expand_head(9), batadv_mcast_forw_push(9), batadv_mcast_forw_mcsend(9)
like, that's the whole group chat and every single one of them is invited π
that's the page!! sourced from ./net/batman-adv, stamped October 2026, and it lives in the Kernel API Manual β batadv_mcas..._scrub_dests(9), slay, bye πβ¨
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms