----- Original Message -----
> On Dec 22, 2010, at 11:02 PM, CAI Qian <[email protected]> wrote:
> 
> >
> >> However, many people use the LTP to test their own linux system, if
> >> those kernel
> >> is not support KSM, at least we should make sure they can build
> >> successfully.
> > In that case, why not use an older version?
> 
> Implementing the fix is trivial. Please write some autoconf tests for
> KSM, et all.
Garrett, yes, it is trivial. If we are going to fix here, there are many
other similar places need the fix too. It adds much headaches and code to
support old distros like RHEL5 and RHEL4. There are also so many distros
and custom kernels out there and there is no way to move anything forwards
to support those including embedded. For examples,

1) AC_PREREQ(2.61) in ltp/configure.ac: this won't support old distros anyway.
2) Even if the test has MADV_MERGEABLE defined, the kernel can still use
   the old interfaces other than the new implementation, so the test will
   definitely broke.
3) if the kernels are buggy, the test will fail as well. It is not scalable
   to fix the test in this case.
4) there are many arches/kernel configuration out there which the new tests
   are not going to compile on them all.

I think it is not a problem for me to fix the compilation here for RHEL5, but
we are still lack of supporting matrix for LTP which has been brought up many
times before without a consensus.

Here is something a proposal going forwards when submitting new tests:
1) compiling tests passed for the current 2.6.x oldest stable release 
(2.6.27.57)
2) compiling tests passed for tool-chains (autoconf, make etc) at least released
   as old as the current 2.6.x stable kernel base release (2.6.27 was released 
in
   Oct 2008; Autoconf 2.63 was released in Sep. 2008 so it should be supported).
3) the tests should give clearly indication of TPASS/TFAIL/TCONF for the current
   2.6.x oldest stable kernel release.

CAI Qian

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Reply via email to