Create a set of utilities that user defined tests can use to gain information during workload setup/execution

[ashmrtn]

User provided tests should have a set of utilities/methods that they can call into which provide them with things like the directory the test file system is mounted at and the file system size.

[ashmrtn]

This functionality can likely be implemented as either methods on the BaseTestCase class which user workloads should inherit from, or a set of standalone utilities. The standalone utilities may be more useful if we plan on allowing users to run CrashMonkey in the background while running a workload.

[vijay03]

I'd prefer this be a command line parameter rather than something used by the user when writing tests. When starting the harness we should allow the user to set this. As for the directory, the user setup sets that up right? So they should already know about it. Setting them as environmental variables seems like a good idea.

On Fri, Jul 14, 2017 at 6:35 PM ashmrtn ***@***.***> wrote: User provided tests should have a set of utilities/methods that they can call into which provide them with things like the directory the test file system is mounted at and the file system size. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA6nph7rwNz6704sUVra6B_sgQQzrIOgks5sOBcsgaJpZM4OY4VS> .

-- Thanks, Vijay Chidambaram http://www.cs.utexas.edu/~vijay/

[ashmrtn]

I agree that the user will probably know about these before-hand when the setup the test harness. However, if we want to have a library of common test cases, we have to be able to efficiently deal with the fact that users could choose different mount directories when running those test cases. In that case, it would be useful to have some set of utilities the test cases could call into to find where they are mounted and things like that.

[vijay03]

I agree with this in principle, but this is very low priority on our list of things to build. Lets go to this once we do the other stuff. One preset directory (like /mnt/test) should be good to start with. Thanks, Vijay Chidambaram http://www.cs.utexas.edu/~vijay/

…

On Fri, Jul 14, 2017 at 6:53 PM, ashmrtn ***@***.***> wrote: I agree that the user will probably know about these before-hand when the setup the test harness. However, if we want to have a library of common test cases, we have to be able to efficiently deal with the fact that users could choose different mount directories when running those test cases. In that case, it would be useful to have some set of utilities the test cases could call into to find where they are mounted and things like that. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA6npgLbbH1qVittq8jMwBEEIqC0oD52ks5sOBuRgaJpZM4OY4VS> .

[ashmrtn]

Sure. Part of the reason for making this is so that it doesn't get forgotten down the road if we wish to make this a more robust system for people to use.