Florian Westphal <fw@xxxxxxxxx> wrote: > Florian Westphal <fw@xxxxxxxxx> wrote: > > Patrick McHardy <kaber@xxxxxxxxx> wrote: > > > > > Any reason why you chose to add this type instead of a generic floating point type? > > > > > > > > I wanted 0.9999 be tranlated to a value close to UINT32_MAX and 0.00001 > > > > to something close to zero so that "meta random 0.999" can be translated to > > > > something like > > > > > > > > reg1 = prandom_u32() > > > > reg1 <= 0xffffffee > > > > > > > > I.e. this type cannot represent 5.2 (or whatever). > > > > > > > > Does that answer your question? > > > > > > Not really unless I'm misunderstanding your intention. That part is > > > related to the kernel internal representation and could be handled > > > during linearization. > > > > So what would you suggest? > > Add support for translating double to mpz_t? > > What precisions would you support? > > So I've started to generalize the proposed precision type > into type_float which would support 0.000000001 as smallest value. > > Does that seem ok or would you use a different precision? > (If so, what & why?) > > What should happen when user asks for meta random 42.23 ? > > That still stands, where would this error be detect best? I've also been unable to figure out where the u32 scaling has to be performed, netlink_linearize.c seems to be a very poor place for this since it would mean special-casing netlink_gen_cmp to check for OP_LTE and presence of EXPR_META with the meta PRANDOM key...? In fact, doing the scaling via precision_type seems to be a lot simpler as then its applied only in this one case of the prandom META_TEMPLATE while keeping this detail limited to meta.c. -- 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
