On 01/21/15 at 08:58pm, Herbert Xu wrote: > On Wed, Jan 21, 2015 at 09:49:28AM +0000, Thomas Graf wrote: > > > > An entry can move between different tables and thus chains need to be > > marked to identify what list a lookup ended up searching in. It's not > > the nulls marker itself that is needed, it's the bits in the last next > > pointer identifying the list that the nulls marker allows to be used > > which are essential. > > Can you describe in more detail how it's going to be used? I don't > see how I could use the bit if you need it to indicate the end of > the list. Another thought: Instead of storing that bit in the next pointer, we could require the user to store this bit, i.e. two new function pointers to rhashtable_params, set_walk_bit() and get_walk_bit(), which take the hashed object as argument and if a rhashtable user requires consistent dumps he can provide these functions to store the flag. -- 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
