Hm, 2.6.35 can lessen the maintenance burden compared to the currently
minimal supported version 2.6.34, because the main trouble comes from the
differences between .34 and .35. So I think I can remove the older kernel
supports gradually and keep supporting 2.6.35 for a while.
That would be appreciated as I think .35 is a pretty stable kernel and
will be in use for a while yet (though I have to admit, I have patched
this kernel extensively).
The problem with it that the reported number can be inaccurate, at least
in two cases:
- Elements can time out, so even if whatever number reported, by the
time it's displayed, the set can even be completely empty. In the case
of a huge set, it can even occur that the number of elements reported
does not match the actual number of elements listed.
- Sets can be updated by the SET target
The first one is the main reason I dropped reporting the number of
elements (the initial design of the new ipset included it).
I see, reasonable point.
OK, would it be possible then to get this figure when I use restore - I
am asking for this because, as you already know, ip ranges may mean
inserting more elements than the range itself and the indicator I used
up until now to determine how many set members I would have (the number
of lines in my restore file) is no longer a reliable indicator, so I
would need to know how many members I have inserted as a result of
restore in order to determine the maxelem value, adjust it and thus save
system resources. Do you see my point?
--
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
