Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > Don't see how, nfct_attr_unset clears the entire attribute. > > I admit that it would be nice if one could re-use existing api... > > > > Right now nfct_attr_set_l(.. ATTR_CONNLABELS..) can be used to assign > > the bit-vector directly (and _get can be used to retrieve the > > label bit-vector). > > You could use a nfct_bitmask object and methods to modify it: > > struct nfct_bitmask *nfct_bitmask_alloc(void) > nfct_bitmask_set_bit(struct nfct_bitmask *, uint16_t bit) > nfct_bitmask_test_bit(struct nfct_bitmask *, uint16_t bit) > nfct_bitmask_unset_bit(struct nfct_bitmask *, uint16_t bit) $ git grep nfct_bitmask zsh: exit 1 What library is that? My search-engine fu fails. > Then you can attach the bitmask to the object: > > nfct_set_attr(ct, ATTR_CONNLABELS, bitmask); > > The setter would do the special handling internally by attaching the > bitmask label to the ct object. Sounds good. > > I think that we should avoid it; else this might become a > > portability nightmare where applications end up > > trying half a zillion names (/etc/xtables, /usr/etc, /usr/local...) > > We can provide some constant to recommend a path. My only concern is > that the hardcoded path may not exist in some filesystem, thus, > forcing to recompile the library. > > Anyway, I think the main user for this will be the conntrack utility > and any netfilter utilities. True. > I'd go for the cache-based approach, ie. store a lookup array in > memory extracted from the file. Oh. I wanted to avoid this to not bloat the library. I'll add a cache. > Examples files usually help to see how the API looks in action, if you > can attach one in the next round, in would be great. Will do. Thanks a lot for your help! -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
