|A||Feb 20, 2004||Initial release, based on an internal document.|
|B||Feb 25, 2004||
|C||Mar 26, 2004||
|D||Apr 05, 2004||
This document describes the main axes the NTPL Stabilization Project is focusing on. It will be updated each time when a new orientation is taken.
early April 2004
We are aiming to release a whitepaper describing the existing NPTL tests, coming mainly from NPTL sources and from LTP (part of which comes from NGPT dev and from Open POSIX Test Suite project), including which features are tested and how they are tested (conformance, test, ...).
This paper will lead to a synthesis showing which features need more testing. This part will be iterative, we will proceed function by function - i.e. once we isolate which tests are needed for a particular function, we will work on those tests and release them.
A priority order will be decided on function treatment order.
Two orientations will be carried on, first is conformance, second includes stress, performance and scalability.
Conformance matters are mainly covered in Open POSIX Test Suite and NPTL source tree tests. There are very few performance comparison tools or stress tools at this time.
This paper will be updated when we release new tests.
As we will need a trace mechanism in NPTL, we want to propose an advanced feature which could be useful to anyone who develops a multithreaded application.
Early April 2004, we will drop a design document, and discuss it with libc developpers and users. This document will explain our goals.
Then once this design is reviewed and approved, we will start the coding and propose our implementation to the NPTL developpers (end of June 2004).
until September 2004
We also plan to produce papers giving comparison of same performance tests over different platforms, including:
First step consists in releasing a lot of small C programs that can be run on as much POSIX-compliant OS as possible (Linux, AIX, Solaris,...) trying to cover almost all NPTL routines. These samples will have multiple goals:
Those samples will be dropped into the LTP project. The use of these samples should lead to improve the reliability of the NPTL subroutines, or at least to prove this reliability.
Second step: intensive stressing, until december 2004.
This will be done either by using the previous tests altogether or by using third party tools like Java benchmarks. The drawback of this part is that even if we find some problems, it might be difficult to find the cause.