Documentation: update kmemleak architecture support info
Quoted 8 lines
I am fine with this. What do you say about having
something generic like:"Please check
DEBUG_KMEMLEAKdependencies inlib/Kconfig.debugfor supported platforms"In this way, there's no need to update kememleak.txt everytime when a new platform is supported.
I think it looks better. I have updated the Documentation as per your suggestion. Please find the modified patch below:
---
Documentation/kmemleak.txt +3 -1
@@ -11,7 +11,9 @@ with the difference that the orphan objects are not freed but only reported via /sys/kernel/debug/kmemleak. A similar method is used by the Valgrind tool (memcheck --leak-check) to detect the memory leaks in user-space applications. -Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze and tile. +Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze, tile, +s390 and mips.Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug +for supported platforms. Usage -----
Documentation/kmemleak.txt with the difference that the orphan objects are not freed but only · line 16
Quoted 4 lines · Maxin B John
Documentation/kmemleak.txt +3
-1-Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze and tile. +Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze, tile, +s390 and mips.Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug +for supported platforms.
The point of adding my generic comment was to remove direct references to supported platforms.
In this case your patch should remove the line specifying supported platforms (x86, arm, powerpc, etc) and only add the line pointing the reader to lib/Kconfig.debug.
When a new platform will be supported lib/Kconfig.debug will be surely modified, and the change will be consistent with information in kmemleak.txt.
Cătălin, what do you think?
thanks,
Daniel.
Quoted 8 lines · Daniel Baluta
Documentation/kmemleak.txt with the difference that the orphan objects are not freed but only · line 16
Quoted 4 lines · Maxin B John
Documentation/kmemleak.txt +3
-1-Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze and tile. +Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze, tile, +s390 and mips.Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug +for supported platforms.The point of adding my generic comment was to remove direct references to supported platforms.
Quoted 7 lines
In this case your patch should remove the line specifying supported platforms (x86, arm, powerpc, etc) and only add the line pointing the reader to
lib/Kconfig.debug.When a new platform will be supported
lib/Kconfig.debugwill be surely modified, and the change will be consistent with information in kmemleak.txt.
I think Daniel's suggestion is better, we don't have to worry about changing the documentation every time we add a new architecture.
In addition to that, I would say "supported architectures" rather than platforms.
Thanks.
Signature · 1 line
Catalin
Quoted 17 lines · On Fri, 10 Jun 2011 15:55:18 +0100 Catalin Marinas wrote:
Quoted 8 lines · Daniel Baluta
Documentation/kmemleak.txt with the difference that the orphan objects are not freed but only · line 16
Quoted 4 lines · Maxin B John
Documentation/kmemleak.txt +3
-1-Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze and tile. +Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze, tile, +s390 and mips.Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug +for supported platforms.The point of adding my generic comment was to remove direct references to supported platforms.
Quoted 7 lines
In this case your patch should remove the line specifying supported platforms (x86, arm, powerpc, etc) and only add the line pointing the reader to
lib/Kconfig.debug.When a new platform will be supported
lib/Kconfig.debugwill be surely modified, and the change will be consistent with information in kmemleak.txt.
Quoted 5 lines
I think Daniel's suggestion is better, we don't have to worry about changing the documentation every time we add a new architecture.
In addition to that, I would say "supported architectures" rather than platforms.
Maxin,
Please send an updated patch without the currently-supported list of architectures.
thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***