Re: [PATCH] xfstests: kill lib/random.c

[Josef Bacik <jbacik@fb.com>]

On 01/07/2014 03:40 PM, Ben Myers wrote:
> On Tue, Jan 07, 2014 at 02:10:15PM -0600, Eric Sandeen wrote:
>> On 1/7/14, 2:01 PM, Ben Myers wrote:
>>> Hey Gents,
>>>
>>> On Mon, Jan 06, 2014 at 03:46:58PM -0600, Eric Sandeen wrote:
>>>> On 1/6/14, 3:42 PM, Josef Bacik wrote:
>>>>> On 01/06/2014 04:32 PM, Eric Sandeen wrote:
>>>>>> On 1/6/14, 1:58 PM, Josef Bacik wrote:
>>>>>>> I was trying to reproduce something with fsx and I noticed that no matter what
>>>>>>> seed I set I was getting the same file.  Come to find out we are overloading
>>>>>>> random() with our own custom horribleness for some unknown reason.  So nuke the
>>>>>>> damn thing from orbit and rely on glibc's random().  With this fix the -S option
>>>>>>> actually does something with fsx.  Thanks,
>>>>>> Hm, old comments seem to indicate that this was done <handwave> to make random
>>>>>> behave the same on different architectures (i.e. same result from same seed,
>>>>>> I guess?)  I . . . don't know if that is true of glibc's random(), is it?
>>>>>>
>>>>>> I'd like to dig into the history just a bit before we yank this, just to
>>>>>> be sure.
>>>>> I think that if we need the output to match based on a predictable
>>>>> random() output then we've lost already. We shouldn't be checking for
>>>>> specific output (like inode numbers or sizes etc) that are dependant
>>>>> on random()'s behaviour, and if we are we need to fix those tests. So
>>>>> even if that is why it was put in place originally I'd say it is high
>>>>> time we ripped it out and fixed up any tests that rely on this
>>>>> behaviour. Thanks,
>>>> Yeah, you're probably right.  And the ancient xfstests history seems to
>>>> be lost in the mists of time, at least as far as I can see.  So I'm ok
>>>> with this but let's let Dave & SGI chime in too just to be certain.
>>> I did not have success locating the history prior to what we have posted on
>>> oss.  I agree that it was likely added so that tests that expose output from
>>> random into golden output files will have the same results across arches.
>>> Maybe this is still of concern for folks who use a different c library with the
>>> kernel.
>>>
>>> Looks there are quite a few callers.  IMO if we're going to remove this we
>>> should fix the tests first.
>> Or first, determine if they really need fixing.  Did you find tests which
>> actually contain the random results in the golden output?
> At one point random.c was modified because it was returning different test
> results on i386 and ia64 with test 007.  Looks like nametest.c is a good
> candidate.
>

Ugh you're right.  Just ignore this patch for now, I'll be in the corner 
banging my head against the wall.  Thanks,

Josef