2010/8/31 Gao, Feng <[email protected]>: > Hi, > > I have tested cacheflush01 testcase in Linux 2.6.27.45 kernel, if the cache > of sys_cacheflush is 0, return value also is Success. It is same with the > Linux 2.6.34.1. > > I have check the kernel code, from the Linux 2.6.11, sys_cacheflush function > began to ignore the cache argument and never return EINVAL. > The function of cacheflush01 is checking if the sys_cacheflush's return > value is correct. if there is no EINVAL as the return value in the kernel > code, it is unnecessary to checking it. Otherwise the case will fail, tester > will waste time to recheck this case and sys_cacheflush function. > > BR, > Feng Gao > > -----Original Message----- > From: Garrett Cooper [mailto:[email protected]] > Sent: 2010-8-31 23:46 > To: Gao, Feng > Cc: ltp-list > Subject: Re: [LTP] [PATCH]Modify the cacheflush01 test case > > 2010/8/31 Gao, Feng <[email protected]>: >> Hi, >> >> The cacheflush system call does not return EINVAL in the latest Linux >> kernel. see the link: >> A related patch about the cacheflush function: >> http://lkml.org/lkml/2009/4/9/203 >> But Ralf had refused this patch: >> http://www.spinics.net/lists/linux-man/msg00906.html >> cacheflush01 testcase checks if the return value is EINVAL when the cache >> argument is not one of ICACHE, BCACHE or DCACHE. So it will fail in all >> boards. >> >> In this modification, checking return value SUCCESS will be added, instead >> of checking EINVAL > > I got the first email :). > > I am always hesitant committing patches like these because unless > there is documentation that clearly states "these are the requirements > for syscall/libcall foo", it can change at a later day without notice > and we'll work ourselves into this funk again. > > Also, what happens when you execute this code on earlier kernels? I > hate getting emails from other users stating "the commit you did for > the test is broke my architecture foo on distro bar -- here's a patch > to fix it!". > > The syscall needs to be fixed. If the cache argument is ignored, it > needs to be removed. Period. And the syscall needs to be renamed to > something else to avoid breaking backwards compatibility (which is > essentially what happened here). > > FWIW we lack positive tests for this syscall, and we really should > have some (other than just nuking the entire contents of the syscall > directory).
Done. If anyone complains that this testcase is broken now, it ain't my fault. -Garrett ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
