On Thu, 9 Jan 2014, Vytas Dauksa wrote: > > 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? I see - good arguments, keep the original operations then. > > 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 -- 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
