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 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.
>
> 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 ?
> 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.
>
> 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
