Fix building error.

PATCH In review Bian Naimeng 3 participants 12 messages Dec 15, 2010 – Dec 27, 2010

lore

Share & tools

lore

Bian Naimeng

author

2010-12-15 06:18 UTC #0 lore raw

PATCH 1/1 Fix building error.

When i build the LTP at RHEL5.5GA, the following error was caught.

make[4]: Entering directory `/home/biannm/gitsrc/ltp-dev/testcases/kernel/syscalls/mmap'
gcc -g -O2 -g -O2 -fno-strict-aliasing -pipe -Wall -I/home/biannm/gitsrc/ltp-dev/testcases/kernel/include -I../../../../include -I../../../../include -L../../../../lib mmap10.c -lltp -lpthread -o mmap10
mmap10.c: In function ‘mmapzero’:
mmap10.c:120: error: ‘MADV_MERGEABLE’ undeclared (first use in this function) mmap10.c:120: error: (Each undeclared identifier is reported only once mmap10.c:120: error: for each function it appears in.)
make[4]: *** [mmap10] Error 1

So, what about this patch?
---------------------------------------------------------------------

KSM is unsupported before 2.6.32. So if MADV_MERGEABLE is undefine, we should not test the following cases.

1. mmap10 with the option "-s".
2. ksm01.

Signed-off-by Bian Naimeng <[email protected]>

---
 testcases/kernel/mem/ksm/ksm01.c        |   15 ++++++++++++---
 testcases/kernel/syscalls/mmap/mmap10.c |    4 ++++
 2 files changed, 16 insertions(+), 3 deletions(-)

testcases/kernel/mem/ksm/ksm01.c +12 -3

index 1143791..9b575ff 100644
@@ -70,12 +70,14 @@
 #include "test.h"
 #include "usctest.h"
 
-#define _PATH_KSM	"/sys/kernel/mm/ksm/"
-#define MB		(1024 * 1024)
-
 char *TCID = "ksm01";
 int TST_TOTAL = 1;
 extern int Tst_count;
+
+#ifdef	MADV_MERGEABLE
+
+#define _PATH_KSM	"/sys/kernel/mm/ksm/"
+#define MB		(1024 * 1024)
 static int opt_num, opt_size;
 static char *opt_numstr, *opt_sizestr;
 /* memory pointer to identify per process, MB, and byte like

@@ -538,3 +540,10 @@ void group_check(int run, int pages_shared, int pages_sharing,
 	check("sleep_millisecs", NULL, sleep_millisecs);
 	check("pages_to_scan", NULL, pages_to_scan);
 }
+
+#else
+int main(int argc, char *argv[])
+{
+	tst_brkm(TRETR, tst_exit, "KSM is unsupported");
+}
+#endif

testcases/kernel/syscalls/mmap/mmap10.c +4 -0

index fe9d622..be988cf 100644
@@ -116,9 +116,13 @@ void mmapzero(void)
 	if (x == MAP_FAILED)
 		tst_brkm(TBROK|TERRNO, cleanup, "mmap");
 	if (opt_ksm) {
+#ifdef	MADV_MERGEABLE
 		tst_resm(TINFO, "add to KSM regions.");
 		if (madvise(x, SIZE+SIZE-4096, MADV_MERGEABLE) == -1)
 			tst_brkm(TBROK|TERRNO, cleanup, "madvise");
+#else
+		tst_brkm(TRETR, cleanup, "KSM is unsupported.");
+#endif
 	}
 	x[SIZE] = 0;

Signature · 20 lines

1.7.0.4




-- 
Regards
Bian Naimeng


------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Bian Naimeng

author

2010-12-21 06:23 UTC #1 lore raw

Hi Garrett, Cai

What do you think about it? Any comments are welcome. ^_^

Regards
Bian

Quoted 77 lines · Bian Naimeng

When i build the LTP at RHEL5.5GA, the following error was caught.
make[4]: Entering directory `/home/biannm/gitsrc/ltp-dev/testcases/kernel/syscalls/mmap'
gcc -g -O2 -g -O2 -fno-strict-aliasing -pipe -Wall -I/home/biannm/gitsrc/ltp-dev/testcases/kernel/include -I../../../../include -I../../../../include -L../../../../lib mmap10.c -lltp -lpthread -o mmap10
mmap10.c: In function ‘mmapzero’:
mmap10.c:120: error: ‘MADV_MERGEABLE’ undeclared (first use in this function) mmap10.c:120: error: (Each undeclared identifier is reported only once mmap10.c:120: error: for each function it appears in.)
make[4]: *** [mmap10] Error 1
So, what about this patch?
---------------------------------------------------------------------
KSM is unsupported before 2.6.32. So if MADV_MERGEABLE is undefine, we should not test the following cases.
1. mmap10 with the option "-s".
2. ksm01.
Signed-off-by Bian Naimeng <[email protected]>
---
 testcases/kernel/mem/ksm/ksm01.c        |   15 ++++++++++++---
 testcases/kernel/syscalls/mmap/mmap10.c |    4 ++++
 2 files changed, 16 insertions(+), 3 deletions(-)
testcases/kernel/mem/ksm/ksm01.c +12 -3
index 1143791..9b575ff 100644
@@ -70,12 +70,14 @@
 #include "test.h"
 #include "usctest.h"
 
-#define _PATH_KSM	"/sys/kernel/mm/ksm/"
-#define MB		(1024 * 1024)
-
 char *TCID = "ksm01";
 int TST_TOTAL = 1;
 extern int Tst_count;
+
+#ifdef	MADV_MERGEABLE
+
+#define _PATH_KSM	"/sys/kernel/mm/ksm/"
+#define MB		(1024 * 1024)
 static int opt_num, opt_size;
 static char *opt_numstr, *opt_sizestr;
 /* memory pointer to identify per process, MB, and byte like
@@ -538,3 +540,10 @@ void group_check(int run, int pages_shared, int pages_sharing,
 	check("sleep_millisecs", NULL, sleep_millisecs);
 	check("pages_to_scan", NULL, pages_to_scan);
 }
+
+#else
+int main(int argc, char *argv[])
+{
+	tst_brkm(TRETR, tst_exit, "KSM is unsupported");
+}
+#endif
testcases/kernel/syscalls/mmap/mmap10.c +4 -0
index fe9d622..be988cf 100644
@@ -116,9 +116,13 @@ void mmapzero(void)
 	if (x == MAP_FAILED)
 		tst_brkm(TBROK|TERRNO, cleanup, "mmap");
 	if (opt_ksm) {
+#ifdef	MADV_MERGEABLE
 		tst_resm(TINFO, "add to KSM regions.");
 		if (madvise(x, SIZE+SIZE-4096, MADV_MERGEABLE) == -1)
 			tst_brkm(TBROK|TERRNO, cleanup, "madvise");
+#else
+		tst_brkm(TRETR, cleanup, "KSM is unsupported.");
+#endif
 	}
 	x[SIZE] = 0;
 

Signature · 14 lines

Regards
Bian Naimeng


------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

CAI Qian

2010-12-21 06:39 UTC #2 lore raw

Hi,

Quoted 1 line

What do you think about it? Any comments are welcome. ^_^

This test is not designed for older kernels like RHEL5.5. Even if fixed the compilation error, the test will not be working correctly due to old KSM interfaces and implementation there.

CAI Qian

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Ltp-list mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Bian Naimeng

author

2010-12-21 07:05 UTC #3 lore raw

Quoted 5 lines · CAI Qian

Hi,
Quoted 1 line
What do you think about it? Any comments are welcome. ^_^
This test is not designed for older kernels like RHEL5.5. Even if fixed the compilation error, the test will not be working correctly due to old KSM interfaces and implementation there.

Thanks for your reply.

Could you tell me which kernels are this test fit to?

If there is old KSM interface, and this test can not work correctly on it, i think we should fix the test, it should not do anything but reports "This test is unsupported!"

Signature · 2 lines

Regards
Bian Naimeng

Quoted 3 lines

CAI Qian

CAI Qian

2010-12-21 07:11 UTC #4 lore raw

Quoted 1 line

Could you tell me which kernels are this test fit to?

It is hard to tell. The old kernel might decide to back-port this feature.

Quoted 3 lines

If there is old KSM interface, and this test can not work correctly on it, i think we should fix the test, it should not do anything but reports "This test is unsupported!"

Anyway, it would be more code to test here and there rather than kernel version. Isn't LTP's guideline to only support the latest and greatest kernels?

CAI Qian

Bian Naimeng

author

2010-12-21 07:34 UTC #5 lore raw

Quoted 2 lines · CAI Qian

Quoted 1 line
Could you tell me which kernels are this test fit to?
It is hard to tell. The old kernel might decide to back-port this feature.

I see.

Would you like tell me what's the test required?

If the test is good, i think it should pass on old kernel which had back-port this feature, otherwise the back-port procedure is incorrect.

Quoted 5 lines

Quoted 3 lines
If there is old KSM interface, and this test can not work correctly on it, i think we should fix the test, it should not do anything but reports "This test is unsupported!"
Anyway, it would be more code to test here and there rather than kernel version. Isn't LTP's guideline to only support the latest and greatest kernels?

En..., i do not know. :)

Thanks
Bian

Quoted 3 lines

CAI Qian

Signature · 14 lines

Regards
Bian Naimeng


------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Garrett Cooper

2010-12-21 08:06 UTC #6 lore raw

Quoted 10 lines · Bian Naimeng

Quoted 2 lines · CAI Qian
Quoted 1 line
Could you tell me which kernels are this test fit to?
It is hard to tell. The old kernel might decide to back-port this feature.
I see.
Would you like tell me what's the test required?
If the test is good, i think it should pass on old kernel which had back-port this feature, otherwise the back-port procedure is incorrect.

Yes, assuming features are tied to specific versions is a bad idea; a lot of code in LTP does this in an effort to be correct as to when it was first implemented, but it's wrong because there are various groups who may have backported support for distro or product specific reasons :)...

Quoted 4 lines

Quoted 4 lines
Quoted 3 lines
If there is old KSM interface, and this test can not work correctly on it, i think we should fix the test, it should not do anything but reports "This test is unsupported!"
Anyway, it would be more code to test here and there rather than kernel version. Isn't LTP's guideline to only support the latest and greatest kernels?

I wish. It would make life a lot easier, but that isn't the way that things are today (esp the folks on here that are running ancient versions of Redhat... *cough*)... and given that trying to track Linux changes is like trying to forecast the weather, stuff is always changing -- for better or for worse -- which makes it a pain for everyone else sitting out on the sidelines, like LTP, because Linux kernel devs don't actively engage test projects. There isn't really a line drawn in the sand as far as what is and isn't supported by LTP, except between 2.4 and 2.6 kernels, and even that is murky in spots.
Thanks,
-Garrett
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Bian Naimeng

author

2010-12-23 06:48 UTC #7 lore raw

Quoted 14 lines · Garrett Cooper

Quoted 9 lines · Bian Naimeng
Quoted 2 lines · CAI Qian
Quoted 1 line
Could you tell me which kernels are this test fit to?
It is hard to tell. The old kernel might decide to back-port this feature.
I see.
Would you like tell me what's the test required?
If the test is good, i think it should pass on old kernel which had back-port this feature, otherwise the back-port procedure is incorrect.
Yes, assuming features are tied to specific versions is a bad idea; a lot of code in LTP does this in an effort to be correct as to when it was first implemented, but it's wrong because there are various groups who may have backported support for distro or product specific reasons :)...

Quoted 7 lines

Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
If there is old KSM interface, and this test can not work correctly on it, i think we should fix the test, it should not do anything but reports "This test is unsupported!"
Anyway, it would be more code to test here and there rather than kernel version. Isn't LTP's guideline to only support the latest and greatest kernels?
I wish. It would make life a lot easier, but that isn't the way that things are today (esp the folks on here that are running ancient versions of Redhat... *cough*)... and given that trying to track Linux changes is like trying to forecast the weather, stuff is always changing -- for better or for worse -- which makes it a pain for everyone else sitting out on the sidelines, like LTP, because Linux kernel devs don't actively engage test projects. There isn't really a line drawn in the sand as far as what is and isn't supported by LTP, except between 2.4 and 2.6 kernels, and even that is murky in spots.

Yes.

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.

Regards
Bian

Quoted 3 lines

Thanks,
-Garrett

Signature · 14 lines

Regards
Bian Naimeng


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

CAI Qian

2010-12-23 07:02 UTC #8 lore raw

Quoted 4 lines

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?

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

Bian Naimeng

author

2010-12-23 07:16 UTC #9 lore raw

Quoted 4 lines · CAI Qian

Quoted 3 lines
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?

But how to choose the older version, it means which LTP is the better one? ^_^ And, maybe a new case is designed to test all versions of linux include the older one.

Quoted 4 lines

CAI Qian

Signature · 14 lines

Regards
Bian Naimeng


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

Garrett Cooper

2010-12-23 19:26 UTC #10 lore raw

In reply to CAI Qian

Quoted 5 lines · CAI Qian

Quoted 4 lines
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
------------------------------------------------------------------------------
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

CAI Qian

2010-12-27 05:27 UTC #11 lore raw

----- Original Message -----

Quoted 11 lines · CAI Qian

Quoted 7 lines
Quoted 6 lines
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