> >> +int32_t odp_random_repeatable_data(uint8_t *buf, uint32_t len, > >> + odp_random_kind_t kind, uint32_t > *seed); > >> > > > > If pseudo/deterministic is not a good term for this, then I think it's > better to profile it strictly for testing (all production cases are > covered by odp_random_data()). Also for testing the kind is not needed, we > just say that: "this is good only for testing, do not use for production". > If kind would be there, it would give two ways to achieve "cryptograptic > quality" randoms and that's not the intention of the call. Also a larger > seed enables better randomness of the output. > > Actually if you want to test the implementation of a cryptographic > algorithm you need repeatable cryptographic data as input. This is > just being consistent across the API. You would never use the > repeatable variant in production and I don't think that would be a > point of confusion. The term "cryptographic quality" simply refers to > the statistical properties of the data, and nothing more should be > read into that term. >
OK. This is then the compromise /** * Generate repeatable random data for testing purposes * * For testing purposes it is often useful to generate "random" sequences * that are repeatable... * * This function should be used only for testing purposes, use odp_random_data() * for production. */ int32_t odp_random_test_data(uint8_t *buf, uint32_t len, odp_random_kind_t kind, uint64_t *seed); -Petri > > > > > > /** > > * Generate repeatable random data for testing purposes > > * > > * For testing purposes it is often useful to generate "random" > sequences > > * that are repeatable... > > * > > * This function should be used only for testing purposes, use > odp_random_data() > > * for production. > > */ > > int32_t odp_random_test_data(uint8_t *buf, uint32_t len, uint64_t > *seed); > > > > > > -Petri > >
