Hi Florent, On Mon, 16 Jul 2018, Florent Fourcot wrote: > > Technically I have no problem with your patch. However, it means a > > non-versioned protocol change. I'd like to think about it and check > > how would be best to introduce a version change. > > Do you have any update on this? In my opinion, there are already some > flags to control list output (LIST_SETNAME and LIST_HEADER), and adding > one more is not really a breaking change. Controlling list output is not the same: kernel versions which do not know the flags simply list the whole sets and userspace handles it fine. The only drawback is the unnecessary data transfer. However with your proposed flag, additional data is returned. I'm concerned about backward compatilibity. What happens when a new userspace tool communicates with an old kernel? The only way to detect the incompatility is to check that the anticipated attributes are missing. But ipset strictly checks the attributes and reports protocol violations. With this solution there's no way to tell the difference between an old kernel or broken protocol. > If you have any hints/idea to improve this patch, I can try to provide a > new version. I want to introduce a new protocol version. Both the kernel and userspace have got the very basic parts to support multiple protocols, however have never been tested, obviously. Also, I'm thinking on adding two new commands to get the set by name and index and not a single one for both operations. The whole thing needs time and I'm busy these weeks with a cluster migration. With a new protocol version, new userspace tools can "negotiate" the old protocol version with old kernels and can easily fall back to the getsockopt solution to get the required data from kernel. 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
