Hi All,
thanks so much for your feedback. My comment below:
>
> 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.
Ok, no problem for me.
>
>>>
>>> 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.
Well, /tmp is ok also for me. I asked it just to make sure about that.
>
>>> 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.
Please, could you send me your opinion about above comment ? I think
it is important to know the needed user privileges before to run it.
>>>
>>> 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.
Ok, thanks! In fact what I got are some failures due to not very clear
reasons ;-) Anyway, I'll read the manpages section you referred and I
back to you about that, even though, I hope to see more "debug-info"
during the utimensat 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.
>
> See above -- the ownership of files specifically effects some of the
> error checking (and returned errors) for utimensat().
Not very clear for me, but I'd like to read the manpages before to
continue this discussion.
Thanks again
Regards
FR
>
> 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
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
------------------------------------------------------------------------------
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
