Re: material to write testcases beased on

> If you have time to look in to the latest code, please then go according
> to the latest code which is there in the Main line Kernel (as i feel
> that the Man pages may not be updated at the pace in which code gets
> patched, updated and finally released). So, our test cases will be
> little ahead of even the man page (eventually the issues will be
> displayed by the next or future man page releases). But please do not
> forget the following points:

I see.

> 1) When you write code, make it backward compatible to all those kernels
> also, where the features is not supported. Your test case should be able
> to compile in all kernels, but will definitely compile different code
> (compile actual code when the kernel supports, and, compile some proper
> message when the kernel does not support),
> 2) Make sure to use the standard log libraries of LTP rather than printf
> family of functions.
> 
> Would like to know others opinion on this. Please pour in your
> suggestions on this.

I see.

I think ideally man pages and test cases should be part of linux kernel.
test cases tests glibc, too. man pages explains user land tool and library.
So the ideal is just an ideal.

How about relationship between writing man pages and test cases?
I think these two activities/projects are very closer.

additional tests for sendfile

Hi,

I wrote additional testcases for sendfile(and sendfile64).

	* Fix typos.

	* sendfile02.c (do_sendfile): Check file position of IN_FD.
	Check the upadted value of OFFSET.

	* sendfile04.c (do_sendfile): Don't use MAP_PRIVATE. UCLINUX
	doesn't support it.

	* sendfile05.c: Testcase to test that sendfile(2) system call 
	returns EINVAL when passing negative offset.

	* sendfile06.c: Testcase to test that sendfile(2) system call 
	updates file  position of in_fd correctly when passing NULL as 
	offset.

	* sendfile07.c: Testcase to test that sendfile(2) system call 
	returns EAGAIN when passing blocked out_fd. Here out_fd is opend
	 with O_NONBLOCK.

Signed-off-by: Masatake YAMATO <yamato@...>

2007-12-02  Masatake YAMATO  <yamato@...>

	* sendfile02.c (do_sendfile): Check file position of IN_FD.
	Check the upadted value of OFFSET.

Re: additional tests for sendfile

Thanks for this. I am doing the Nov 2007 release today and will probably
check this in today or early tomorrow.

--Subrata

On Sun, 2007-12-02 at 04:23 +0900, Masatake YAMATO wrote:
> Hi,
> 
> I wrote additional testcases for sendfile(and sendfile64).
> 
> 	* Fix typos.
> 
> 	* sendfile02.c (do_sendfile): Check file position of IN_FD.
> 	Check the upadted value of OFFSET.
> 
> 	* sendfile04.c (do_sendfile): Don't use MAP_PRIVATE. UCLINUX
> 	doesn't support it.
> 
> 	* sendfile05.c: Testcase to test that sendfile(2) system call 
> 	returns EINVAL when passing negative offset.
> 
> 	* sendfile06.c: Testcase to test that sendfile(2) system call 
> 	updates file  position of in_fd correctly when passing NULL as 
> 	offset.
> 
> 	* sendfile07.c: Testcase to test that sendfile(2) system call 
> 	returns EAGAIN when passing blocked out_fd. Here out_fd is opend
> 	 with O_NONBLOCK.
> 
> Signed-off-by: Masatake YAMATO <yamato@...>

[ANNOUNCE] The Linux Test Project has been Released for NOVEMBER 2007

Dear All,

The Linux Test Project test suite has been released for the month of
NOVEMBER 2007. The latest version of the test-suite contains 3000+
tests for the Linux OS and can be found at http://ltp.sourceforge.net/.
Latest happenings in LTP can also be found at:
http://ltp.sourceforge.net/wiki/,
http://ltp.sourceforge.net/wikiArchives.php, and,
IRC: irc.freenode.org #ltp.

Our web site also contains other information such as:
- A Linux test tools matrix
- Technical papers
- How To's on Linux testing
- Code coverage analysis tool.

Release Highlights:

* Several Network Test Cases has been updated to be run on different
subnet configuration,
* Updated lot of Test Cases to enable them run on NFS,
* Addition of posix_fadvise, fadvise64, madvise03, sendfile64 &
sendfile04 Test Cases to LTP
* Existing code in LTP-Kdump has been enhanced to test dump on Network
and different partitions, added IA64 support to KDUMP and lots of
changes in KDUMP scripts for error correction and improvement,
* Option to generate more parsible output in HTML format has been added,
* Option to automatically mail back LTP reports has been added,
* OpenHPI 2.10.1 has been integrated to LTP,
* Updated several Test Cases for suiting to proper GPLv2 License,

Openposix: pthread create, testcase 1-6

Hey all,
I have a question on testcase pthread_create/1-1.c :
there is shared variable "int *ctrl = (int *) arg;" in function
"hp_func" which should be protected through pthread_mutex or similar, right?
As I understand this shared variable should always be protected?
So is there a reason why there are no pthread synchronisation calls?

As you can see in the suggested temporary patch below, is it possible to
add volatile-statement to the shared variables?

I'm asking, because sometimes this testcase fails on s390x.

---
testcases/open_posix_testsuite/conformance/interfaces/pthread_create/1-6.c
+++
testcases/open_posix_testsuite/conformance/interfaces/pthread_create/1-6.c
 <at>  <at>  -111,7 +111,7  <at>  <at> 

 void * hp_func(void * arg)
 {
-       int *ctrl = (int *) arg;
+       volatile int *ctrl = (int *) arg;
        int dummy=0, i;
        do
        {

Thanks for advice,
--

-- 
Patrick Kirsch - Quality Assurance Department
SUSE Linux Products GmbH GF: Markus Rex, HRB 16746 (AG Nuernberg)

Re: Openposix: pthread create, testcase 1-6

On Monday 03 December 2007, Patrick Kirsch wrote:
> I have a question on testcase pthread_create/1-1.c :
> there is shared variable "int *ctrl = (int *) arg;" in function
> "hp_func" which should be protected through pthread_mutex or similar,
> right? As I understand this shared variable should always be protected?
> So is there a reason why there are no pthread synchronisation calls?
>
> As you can see in the suggested temporary patch below, is it possible to
> add volatile-statement to the shared variables?
>
> I'm asking, because sometimes this testcase fails on s390x.

perhaps look at the generated assembly code and see if gcc is incorrectly 
optimizing away memory loads ?  adding volatile sounds like you're ignoring a 
deeper problem ...
-mike

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: Developer's Certificate of Origin

On Fri, Nov 30, 2007 at 04:22:27PM -0600, Kumar Gala wrote:
> On Nov 30, 2007, at 12:03 PM, George Kraft wrote:
> > On Fri, 2007-11-30 at 10:02 -0600, Kumar Gala wrote:
> >> I think CVS provides a barrier of entry for people that GIT reduces.
> >> For example its a PITA for me to create diffs w/CVS because the speed
> >> of CVS to the sf.net server is horrendous for me.
> >
> > Kumar,
> >
> > Then you don't really have an issue with CVS but rather with the
> > throughput of the service that SF.net is providing.
> 
> I also have issues with CVS :)
> 
> but I think I'll resolve all this by importing ltp into git and just  
> using it that want and proving patches.

If you do can you make a public git tree so I can clone it?  :)

I think LTP has the potential to move in many different directions.  git
would help people try out different direction or manage their local
modifications while still enabling them to merge back to the base LTP or
publish their own branch for the community to evaluate and use.

This podcast, "FLOSS Weekly 19: git" really helped me understand git
better.  I would be all for using it.
http://twit.tv/floss19

Nate

Re: Developer's Certificate of Origin

On Dec 4, 2007, at 7:18 AM, Nate Straz wrote:

> On Fri, Nov 30, 2007 at 04:22:27PM -0600, Kumar Gala wrote:
>> On Nov 30, 2007, at 12:03 PM, George Kraft wrote:
>>> On Fri, 2007-11-30 at 10:02 -0600, Kumar Gala wrote:
>>>> I think CVS provides a barrier of entry for people that GIT  
>>>> reduces.
>>>> For example its a PITA for me to create diffs w/CVS because the  
>>>> speed
>>>> of CVS to the sf.net server is horrendous for me.
>>>
>>> Kumar,
>>>
>>> Then you don't really have an issue with CVS but rather with the
>>> throughput of the service that SF.net is providing.
>>
>> I also have issues with CVS :)
>>
>> but I think I'll resolve all this by importing ltp into git and just
>> using it that want and proving patches.
>
> If you do can you make a public git tree so I can clone it?  :)
>
> I think LTP has the potential to move in many different directions.   
> git
> would help people try out different direction or manage their local
> modifications while still enabling them to merge back to the base  
> LTP or
> publish their own branch for the community to evaluate and use.

Re: [PATCH] Update CLONE_NEWPID in libclone.h

Applied. Thanks.

--Subrata

On Wed, 2007-10-10 at 18:08 -0700, sukadev@... wrote:
> CLONE_NEWPID value changed in 2.6.23-rc3-mm2. Update libclone.h to reflect
> that change.
> 
> Since the new value conflicts with CLONE_NEWNET3 and since NEWNET2 and
> NEWNET3 are unsed at present, this patch removes them for now. We can
> add them back once their value is "locked in" in sched.h.
> 
> Signed-off-by: Sukadev Bhattiprolu <sukadev@...>
> ---
> 
> Index: ltp-full-20070930/testcases/kernel/containers/libclone/libclone.h
> ===================================================================
> --- ltp-full-20070930.orig/testcases/kernel/containers/libclone/libclone.h      2007-10-10
17:16:22.000000000 -0700
> +++ ltp-full-20070930/testcases/kernel/containers/libclone/libclone.h   2007-10-10
17:17:19.000000000 -0700
>  <at>  <at>  -54,16 +54,8  <at>  <at> 
>  #define CLONE_NEWUSER          0x10000000
>  #endif
> 
> -#ifndef CLONE_NEWNET2
> -#define CLONE_NEWNET2          0x20000000
> -#endif
> -
> -#ifndef CLONE_NEWNET3

Re: additional tests for sendfile

Thanks. This is Added.

--Subrata

On Sun, 2007-12-02 at 04:23 +0900, Masatake YAMATO wrote:
> Hi,
> 
> I wrote additional testcases for sendfile(and sendfile64).
> 
> 	* Fix typos.
> 
> 	* sendfile02.c (do_sendfile): Check file position of IN_FD.
> 	Check the upadted value of OFFSET.
> 
> 	* sendfile04.c (do_sendfile): Don't use MAP_PRIVATE. UCLINUX
> 	doesn't support it.
> 
> 	* sendfile05.c: Testcase to test that sendfile(2) system call 
> 	returns EINVAL when passing negative offset.
> 
> 	* sendfile06.c: Testcase to test that sendfile(2) system call 
> 	updates file  position of in_fd correctly when passing NULL as 
> 	offset.
> 
> 	* sendfile07.c: Testcase to test that sendfile(2) system call 
> 	returns EAGAIN when passing blocked out_fd. Here out_fd is opend
> 	 with O_NONBLOCK.
> 
> Signed-off-by: Masatake YAMATO <yamato@...>
> plain text document attachment (sendfile2.patch)