Peter Maydell <peter.mayd...@linaro.org> writes:
> On Fri, 5 May 2023 at 01:23, Jun Sun <j...@junsun.net> wrote: >> >> Agree on the usefulness of generating the same test. That is the >> reason behind adding --randseed option. Once a seed is set, it >> always generates the same sequence of instructions. >> >> Basically with this patch, >> >> by default you will generate random instruction sequences for most testing >> cases >> you can provide a random seed option in the commandline to generate a >> deterministic instruction sequence >> >> Without this patch, >> >> we always get one fixed sequence (ie. random seed == 0 case) >> Otherwise we would have to manually modify code to generate random >> instruction sequences or generate a different fixed sequence. >> >> Hope this clarifies things a little bit. > > Mmm; it comes down to: should we default to 'time' and > require the user to specify --randseed 0 to get the old > behaviour; or do we retain the current behaviour as the > default and let the user pass an option if they want a > non-reproducibly random output. > > Alex, what do you reckon? You probably have been using > risugen more actively than me recently. I guess I vaguely > lean to "default to randomize(time)". I'm easy either way as long as we as long as we print out the seed so we can deterministically regenerate if we want to. > > Also, should we make risugen print the random seed to stdout > so you can repro it even if you didn't pass --randseed initially? > > Now that the random-seed-setting is 6 lines instead of 1, > this should definitely be abstracted out to a function > in the common code and not repeated in each per-arch file. > > thanks > -- PMM -- Alex Bennée Virtualisation Tech Lead @ Linaro
