On Wed, 2 Jul 2008, Thomas Jacob wrote:
I am not familiar enough with the iptables code to decide whether or not chains are always sorted by name in the kernel, and thus will be sorted if you read them back, but if that's the case, of course your method is better, as long as that's always the case...
It _is_ always the case that chains are sorted by name in the kernel, as libiptc puts them in sorted.
Thats also what the chain_index code depends upon (although I have build in a safe guard that sorts them if they are not). There is also a safe guard for the offset binary search, but that simply reverts to the old (_slow_) search scheme.
If Patrick might want to change this in the future, he should consider your solution over mine.
To be honest, I didn't really understand the chain_index code ;)
It actually some what resembels your idea, with arrays of chain_head pointers. That points to the original chain list. I don't build "chunks" as I don't want to find an exact match, just a place in the chain list to start the list search. This is choosen because I need to support chains deletes and creates.
Its more complicated because it needs to support chain deletes and creates. And needs to scale, when many chains are added, which requires rebuilding the chain_index, but not too often...
BTW, I like your coding style, although it more compact that I would choose to write it...
Hilsen Jesper Brouer -- ------------------------------------------------------------------- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk ------------------------------------------------------------------- -- 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
