On Sat, Jun 9, 2012 at 8:24 PM, <merez@xxxxxxxxxxxxxx> wrote: > >> On Thu, Jun 7, 2012 at 1:14 AM, Maya Erez <merez@xxxxxxxxxxxxxx> 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 can be done on the device. no-op is not the right scheduler for the example you mentioned (eMMC), so such device has to be mounted only for the purpose 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 sysfs instead 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. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
