[LTP] [PATCH] consolidate 4 TCs message_queue_test_02_* into message_queue_test_02.sh to avoid fail in case of random execution

[fixed-term.Oleksij.Rempel <fixed-term.Oleksij.Rempel@de.bosch.com>]

On 18.07.2016 13:59, Cyril Hrubis wrote:
> Hi!
>>>>  sem02 sem02
>>>>
>>>>  message_queue_test_01		message_queue_test_01
>>>> -message_queue_test_02_get	message_queue_test_02_get
>>>> -message_queue_test_02_snd	message_queue_test_02_snd
>>>> -message_queue_test_02_rcv	message_queue_test_02_rcv
>>>> -message_queue_test_02_ctl	message_queue_test_02_ctl -r
>>>> +message_queue_test_02		message_queue_test_02.sh
>>>>  message_queue_test_04		message_queue_test_04
>>>>  message_queue_test_05		message_queue_test_05
>>>>  pipe_test_01			pipe_test_01
>>>
>>> This is exactly against our guidelines, see:
>>>
>>> https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines#211-runtest-
>>> files
>>
>> What exactly do you mean?
> 
> What I mean and is written in the guidelines is:
> 
> The runtest files should have one entry per a test. Creating a wrapper
> that runs all your tests and adding it as a single test into runtest
> file is strongly discouraged.
> 
>> To avoid confusions I need to explain background of this patch: We
>> working on remote execution of LTPs on the target. It means, some
>> script is taking test list and execute each of entry over ssh.  In
>> this case we are able to track resets and continue testing after it.
>>
>> So, now we found that some resets are not actially triggered by some
>> specific test. So we decided to randomize test order.  This allowed us
>> to find some more bugs on the system, but introduced issues with tests
>> which depend on each other. For example message_queue_test_02_* can be
>> executed only in some specific order.
> 
> Ah, so they depend on each other. That is a valid reason for executing
> them in a defined order.
> 
> You should have written better patch description since this is not
> exactly clear.

Yea, we are learning to work with upstream directly :)
It will take some time until the patches will be good from first try.

>> What would be the proper way to solve this issue?
> 
> Looking at the code we should probably avoid running these testcasese in
> ipc runtest file, since they were designed to be executed in a loop to
> stress the target system. They does not seem very useful when they are
> executed just once as from the runtest file.

Hmm.. so, they can be removed for now?
Or there is some other place for this kind of tests?
How about cpuhotplug* tests? Some times they fail, but since they are
executed only once, i would expect bad reproducibility.