Re: [ANNOUNCE] ipset 6.6 released

[Mr Dash Four <mr.dash.four@googlemail.com>]

> 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?