On Mon, 9 Mar 2015, Eric B Munson wrote: > > The new line in the output "breaks" any script which parses the > > listing and not prepared that such change may occur (actually, the > > testsuite itself must be fixed therefore too). At the same time I > > don't really like the idea of a new flag to turn on the printing of > > the info - just print it. > > I will make sure that V2 includes any necessary changes to the test suite. Thanks in advance. > > The listing becomes non-uniform and type-dependent, because it's > > restricted to the hash types. But therefore should we add the > > listing of the number of elements to the bitmap and list types too? > > For the hash types, the data comes free - for the other types is > > must be calculated at every listing. > > This is the reason I only added it for the hash type. I don't have > any objection to adding it to the bitmap and list types as well but I > didn't have a consumer for that information in mind to justify the > extra calculations at run time. Plus, the libipset consumer could > count entries in output just as well as the library itself. That would be a little complicated (I mean to count the entries from libipset): the library should cache all the entries to count them, finish printing the header by the element count and then print the elements. But "ipset" supports the terse list mode when just the header is listed, without the elements. So I believe it's just better to calculate the element count in the kernel header function for the bitmap and list types as well. It can be a lazy counting, without taking into account the possible timed out entries: that way the element counter is at least consistent. Let's skip bumping the revision numbers for the set types. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary -- 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
