Hi Subrata, Francesco, [Subrata: please use my mtk.manpages@ address for API related stuff.]
Some notes below. On Fri, Mar 13, 2009 at 1:31 AM, Subrata Modak <[email protected]> wrote: > Redirecting these set of queries to Michael Kerrisk, the original author > of these tests. > > Regards-- > Subrata > > On Thu, 2009-03-12 at 13:25 +0100, Francesco RUNDO wrote: >> Hi Subrata, >> >> thanks so much for your feedback and CVS commit. >> I understood also the practical reasons for which you prefer to keep >> the usage of "tst_kvercmp()". >> >> Now, I'd like to open a discussion about the usage of "sudo" and >> "useradd/userdel" in the utimensat testcase. The useradd and usedel stuff was added by someone else -- Subrata I guess. My original test script used sudo, and was designed to be driven from the command line, and would require the user to enter the su password. I passed my test script and program to Subrata, but it wasn't in the standard form required for LTP, and someone, I assume Subrata, kindly did some work to adapt it for LTP; but, probably, it would have been written in a different way (better for LTP) if it had been originally written for LTP from the beginning. >> The script "utimensat_tests.sh" performs a creation/removal of a new >> user "$user_tester", temporarily: >> >> 1) user_tester=utimensat_tester >> useradd $user_tester >> >> That user is deleted, at the end of test-execution, by means of >> "userdel -r utimensat_tester" command. >> >> Moreover, the utimensat main script (utimensat_tests.sh) performs some >> "sudo" operations such as: >> >> *) sudo chattr -ai $FILE and >> *) sudo -u $user_tester touch $FILE >> ....and so on. >> >> At runtime, all the used files are created/managed under /tmp. Yes, that was how I did things, for convenience in my original test script. That made it easy for others to use the script. But, in a suitable test framework, a suitable locally created directory could also be used. >> Now, my advices/considerations are the following: >> >> 1) the utimensat test should advice by means of a warning or something >> like that (at runtime) that it needs "root" privileges or specific >> privileges. >> This, becuase the utimensat test needs to add/remove a new user >> account temporarily. Otherwise, ad-hoc /etc/suoders config can be >> release/installed in order to give to the user the needed privileges >> to run the testcase. >> >> 2) Which is/are the reason(s) to add and remove a new user during test >> execution ? Some of the error case tests for utimensat() depend specifically on whether a file is owned by another user, or by the process calling utimensat(). (Have a good read of the ERRORS section in the man page -- the details are surprisingly complex.) My solution in the original script was to run that script from a standard user account, and the script would create some files owned by root. In the adaptation to LTP it sounds as though this got changed, so that the "other user" was another unprivileged user rather than root. >> 3) Which is/are the reason(s) to run some file operations (such as >> "touch" or re-direction with ">") under /tmp, by using sudo ? As the >> files are under /tmp, I think the usage of sudo is not necessary. See above -- the ownership of files specifically effects some of the error checking (and returned errors) for utimensat(). Cheers, Michael >> Thanks for your feedback/support. >> >> Best Regards, >> FR >> >> Subrata Modak wrote: >> > Hi, >> > >> > On Tue, 2009-03-10 at 13:54 +0100, Francesco RUNDO wrote: >> > >> > > Hi All, >> > > >> > > I'd like to submit a change to be done on utimensat testcase. >> > > >> > > This test performs a kernel version check both at build time and >> > > runtime. At build time, the test performs a check at makefile level: >> > > >> > > @set -e; $(MAKE) check_for_utimensat_support; \ >> > > if './check_for_utimensat_support' > /dev/null 2>&1; then \ >> > > $(MAKE) utimensat01; \ >> > > else echo "System does not support utimensat syscall support"; true; >> > > fi >> > > >> > > check_for_utimensat_support: check_for_utimensat_support.c >> > > $(CC) $(CFLAGS) -o $@ $< ../../../../lib/tst_kvercmp.c >> > > -I../../../../include >> > > >> > > The same check is also repeated in the "install" target of the same >> > > Makefile. >> > > Moreover, at runtime the script "utimensat_tests.sh" used to run the >> > > test (by standard runltp script) performs again the same check: >> > > >> > > if tst_kvercmp 2 6 22 ; then >> > > tst_resm TCONF "System kernel version is less than 2.6.22" >> > > tst_resm TCONF "Cannot execute test" >> > > exit 0 >> > > fi >> > > >> > > Now, my opinion about that is the following: >> > > >> > > 1) for i386 arch: >> > > One of the above checks should be removed. >> > > >> > >> > True. >> > >> > >> > > 2) for cross-build: >> > > The above structure of the test is really a problem. In fact, at build >> > > time the Makefile (as it is) cross-builds (by ${CC} env var.) the binary >> > > "check_for_utimensat_support" which, clearly, can't be executed on the >> > > host side (even though it will detect the "host" kernel version and not >> > > the "target" ones!). >> > > I cross-build & run LTP on SH based archs so that the utimensat testcase >> > > failed at runtime as the binary utimensat01 wasn't copied to >> > > $LTPROOT/testcases/bin due to error on "check_for_utimensat_support" >> > > execution (Exec format error. Wrong Architecture). >> > > >> > > I've solved the above problem disabling the check of the kernel version >> > > at build time (removing the check on the Makefile). I keep only the >> > > check at runtime. >> > > >> > >> > Yes, that is the way to solve the CROSS build problems. Hence, i have >> > checked in this portion of the patch. You can also look into some other >> > tests (probably testcases/kernel/containers, etc) where the same has >> > been done, and needs rectification. >> > >> > >> > > At the end, I'd like to suggest to use the macro(s) reported on the >> > > header "linux/version.h" instead of a custom approach, for checking the >> > > kernel version. >> > > >> > >> > What happens when your distro kernel has say 2.6.18 kernel. And then you >> > get the 2.6.28 sources, build and reboot in the new kernel ?? >> > >> > tst_kvercmp() compares with the presently running kernel (internally >> > through uname -a), rather than something installed earlier. >> > >> > Regards-- >> > Subrata >> > >> > >> > > The attached patch shows the above approach applied to the >> > > "check_for_utimensat_support.c" source file. >> > > >> > > I'm using an LTP-20090131 + kernel 2.6.23. The hw is SH. >> > > >> > > Please, let me know about the issues above described. >> > > >> > > Thanks so much. >> > > Best Regards, >> > > FR >> > > >> > > plain text document attachment >> > > (ltp-full-20090131-remove-kern_check-utimensat.patch) >> > > This patch removes the kernel version check at build time as it can't be >> > > used for test cross-building. Moreover, the same check is also performed >> > > at runtime. >> > > Signed-off-by: Francesco Rundo <[email protected]> >> > > --- >> > > ltp-full-20090131/testcases/kernel/syscalls/utimensat/Makefile.original >> > > 2009-03-10 11:45:56.109998000 +0100 >> > > +++ ltp-full-20090131/testcases/kernel/syscalls/utimensat/Makefile >> > > 2009-03-10 13:44:35.889999000 +0100 >> > > @@ -23,10 +23,8 @@ >> > > TARGETS = $(patsubst %.c,%,$(SRCS)) >> > > >> > > all: >> > > - @set -e; $(MAKE) check_for_utimensat_support; \ >> > > - if './check_for_utimensat_support' > /dev/null 2>&1; then \ >> > > - $(MAKE) utimensat01; \ >> > > - else echo "System does not support utimensat syscall support"; true; fi >> > > + @set -e; $(MAKE) check_for_utimensat_support; >> > > + $(MAKE) utimensat01; >> > > >> > > check_for_utimensat_support: check_for_utimensat_support.c >> > > $(CC) $(CFLAGS) -o $@ $< ../../../../lib/tst_kvercmp.c >> > > -I../../../../include >> > > @@ -35,9 +33,7 @@ >> > > @set -e; \ >> > > chmod 755 utimensat_tests.sh; \ >> > > ln -f utimensat_tests.sh ../../../bin/utimensat_tests.sh; \ >> > > - if './check_for_utimensat_support' > /dev/null 2>&1; then \ >> > > - for i in $(TARGETS); do ln -f $$i ../../../bin/$$i ; done \ >> > > - else echo "System does not support utimensat syscall support"; true; fi >> > > + for i in $(TARGETS); do ln -f $$i ../../../bin/$$i ; done >> > > >> > > clean: >> > > rm -f $(TARGETS) >> > > plain text document attachment >> > > (ltp-full-20090131-fix-utimensat-check-kernel.patch) >> > > This patch replaces a custom method to check kernel version with a >> > > standard ones. >> > > Signed-off-by: Francesco Rundo <[email protected]> >> > > --- >> > > ltp-full-20090131/testcases/kernel/syscalls/utimensat/check_for_utimensat_support.c.original >> > > 2009-03-10 11:11:20.669999000 +0100 >> > > +++ >> > > ltp-full-20090131/testcases/kernel/syscalls/utimensat/check_for_utimensat_support.c >> > > 2009-03-10 11:14:39.819997000 +0100 >> > > @@ -1,8 +1,9 @@ >> > > #include <stdio.h> >> > > #include <test.h> >> > > +#include <linux/version.h> >> > > >> > > int kernel_support_available(void) { >> > > - if (tst_kvercmp(2,6,22) < 0) >> > > + if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,22)) >> > > return 1; >> > > return 0; >> > > } >> > > ------------------------------------------------------------------------------ >> > > _______________________________________________ >> > > Ltp-list mailing list >> > > [email protected] >> > > https://lists.sourceforge.net/lists/listinfo/ltp-list >> > > >> > >> > >> > > > ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
