Hi! On 09/16/2013 05:03 PM, [email protected] wrote: > Hi! >> >> ifneq ($(KERNELRELEASE),) >> >> -obj-m := test_block.o test_genhd.o >> +obj-m := ltp_block_dev.o >> + >> else >> -KDIR := /lib/modules/$(shell uname -r)/build >> -PWD := $(shell pwd) >> >> -modules: >> - $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules >> +top_srcdir ?= ../../../../.. >> +include $(top_srcdir)/include/mk/testcases.mk >> >> -clean: >> - $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) clean >> - rm -f modules.order >> +MAKE_TARGETS := ltp_block_dev.ko >> >> -help: >> - $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) help >> +# Ignoring the exit status of commands is done to be forward compatible with >> +# kernel internal API changes. The user-space test will return TCONF, if it >> +# doesn't find the module (i.e. it wasn't built either due to kernel-devel >> +# missing or module build failure). >> +%.ko: %.c >> + -$(MAKE) -C $(LINUX_DIR) M=$(abs_srcdir) >> + -mv $@ $@~ >> + -$(MAKE) -C $(LINUX_DIR) M=$(abs_srcdir) clean >> + -mv $@~ $@ > Now that we have more uses of this Make recipe I would love to see it > moved to a file under include/mk/ to avoid duplication. > module.mk is OK? >> * >> * Changes: >> + * Sep 2013 0.3 Changed test-case behavior: major number greater >> + * than 255 is valid, empty device name is valid. >> + * Added test-case result. >> + * Added test-case: unregister_blkdev() with NULL name. >> + * Added command line parameter 'a': run all test-cases. > Please do not add any more changelogs into sources, use git commit > message instead. OK, I wrote the same in the commit message. >> +{ >> + tst_resm(TFAIL, "Test Case %d failed", curr_test_case); > Hmm, wouldn't this print FAIL and the SUCCESS in case the test failed? > (as the main loop prints SUCCESS unconditionally) In case of insmod error, tst_module_load() will call cleanup function (we're passing tst_fail()) and then test exit with TBROK and it will never print PASS. > Shouldn't we rather set a flag here (reset it before each test) and > print PASS/FALL accordingly? > This function will be called after test-case failure only once. > How do we distinguish missing module (due to possible compilation > failure) and test failure? dmesg output can be inspected. If test fail module will print message with description. >> +} >> + >> +static void test_run(void) >> +{ >> + int off = 0; >> + int test_case[] = { 1, 2, 5, 3, 4, 10, 6, 7, 8 }; > What a strange sequence. Is this order of testcases required? Why we > have testcase 10 but not testcase 9? > I think this is a sequence where test-cases's harmless decreasing to the end. Perhaps, there were more test-cases earlier... I'm not an author of this test, so I can only guess. >> + /* >> + * test-cases #7 and #8 can crash the kernel. >> + * We have to wait for kernel fix where register_blkdev()& >> + * unregister_blkdev() checks the input device name parameter >> + * against NULL pointer. >> + */ >> + if (!run_all_testcases) >> + off = 2; > Are you working on fix with kernel devs? > Not me, patch sent to upstream: http://www.gossamer-threads.com/lists/linux/kernel/1780670
------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
