On Sat, Jun 9, 2012 at 8:24 PM, <merez@codeaurora.org> wrote:>>> On Thu, Jun 7, 2012 at 1:14 AM, Maya Erez <merez@codeaurora.org> wrote:>>> The test scheduler allows testing a block device by dispatching>>> specific requests according to the test case and declare PASS/FAIL>>> according to the requests completion error code>>>>> I can't get the point. Isn't this possible purely from userspace using>> IOCTLs ?>> Even otherwise, requiring to modify the scheduler for each test case>> is definitely not scalable.> The main benefit of the test-iosched is the ability to determine the> timing of each request that is being dispatched and to put on hold the> real FS requests so that they won't affect the tests scenario.

Then a potentially long running test can block any useful work that canbe done on the device. no-op is not the right scheduler for the exampleyou mentioned (eMMC), so such device has to be mounted only for thepurpose of running the tests.So using standard noop + debugfs would be sufficient for 99% of the cases ?

> It also allows each block device to determine pass/fail result taking into> account the expected behavior and the actual result.

> The scheduler doesn't have to be changed per tests case. What made you> think it should be?Err.. I misread this section of documentation. I read is as sysfsinstead of debugfs.My mistake..<Quote>+Each test is exposed via debugfs and can be triggered by writing to+the debugfs file. In order to add a new test one should expose a new debugfs+file for the new test.</Quote>

> Currently we use the test-iosched to test the eMMC4.5 features (such as> BKOPs, packed commands and sanitize). I hope that after we will release> the tests later this week it will be clearer.>>Sure. It'd be useful.