> Why it's important that the kernel should mask the mark value, when the > user could add the intended value directly? The only case where it's > required when entries added/deleted by the SET target. It's more natural > for me if the markmask value has a meaning and effect for kernel side > add/del operations only, and ignored for user add/del/test and kernel > tests. What's your opinion? The kernel must apply the mask at test time - that's the whole reason for it. In our use case the desired mask is 0xff000000, because those bits identify the protocol, and the other bits are for an unrelated purpose. Because the other bits could be set to anything, without a mask there might have to be 2^24 entries for the other possible values. If the kernel applies a mask on test, but values added by the user aren't masked, those entries would never match. It seems clearer to mask them at add time, so that the user gets sensible errors; for instance, adding two different values which mask to the same thing will give the same error as adding the same value twice. Another option we discounted was that each entry could have its own mask. This didn't make sense because they're not strictly ordered like netmasks, so multiple entries could be equally applicable, and no hashing is possible. If 12000000/ff000000 and 00340000/00ff0000 are in the set, but one is nomatch, and a packet has mark 12345678, which entry should take effect? > A small thing, but I'd prefer if the mark value were printed/saved in hex > instead of decimal, similarly to iptables. Better introduce a new print > function for it. Sure, will implement this on Friday > 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 -- Vytas Dauksa Junior Developer vytas.dauksa@xxxxxxxxxxxxxx Smoothwall Ltd Phone: +44 (0) 8701 999500 www.smoothwall.net -- 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
