Kmemleak now supports s390 and mips too.
Signed-off-by: Maxin B. John <[email protected]>
---
diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt
index 090e6ee..82833ff 100644
--- a/Documentation/kmemleak.txt
+++ b/Documentation/kmemleak.txt
@@ -11,7 +11,8 @@ 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.
Usage
-----
On 06/09/2011 09:59 PM, Maxin B John wrote:
> Kmemleak now supports s390 and mips too.
>
> Signed-off-by: Maxin B. John<[email protected]>
> ---
> diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt
> index 090e6ee..82833ff 100644
> --- a/Documentation/kmemleak.txt
> +++ b/Documentation/kmemleak.txt
> @@ -11,7 +11,8 @@ 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.
>
> Usage
> -----
Hello,
I am fine with this. What do you say about having
something generic like:
"Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug
for supported platforms"
In this way, there's no need to update kememleak.txt everytime
when a new platform is supported.
thanks,
Daniel.
> I am fine with this. What do you say about having
> something generic like:
>
> "Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug
> for 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:
Signed-off-by: Maxin B. John <[email protected]>
---
diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt
index 090e6ee..0915667 100644
--- a/Documentation/kmemleak.txt
+++ b/Documentation/kmemleak.txt
@@ -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
-----
On 06/10/2011 10:09 AM, Maxin B John wrote:
> -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.
On Fri, Jun 10, 2011 at 08:18:50AM +0100, Daniel Baluta wrote:
> On 06/10/2011 10:09 AM, Maxin B John wrote:
> > -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.
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.
--
Catalin
On Fri, 10 Jun 2011 15:55:18 +0100 Catalin Marinas wrote:
> On Fri, Jun 10, 2011 at 08:18:50AM +0100, Daniel Baluta wrote:
> > On 06/10/2011 10:09 AM, Maxin B John wrote:
> > > -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.
>
> 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 ***
>> I think Daniel's suggestion is better, we don't have to worry about
>> changing the documentation every time we add a new architecture.
I agree with that.
> Please send an updated patch without the currently-supported list
> of architectures.
Please find the updated patch below:
Signed-off-by: Maxin B. John <[email protected]>
---
diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt
index 090e6ee..51063e6 100644
--- a/Documentation/kmemleak.txt
+++ b/Documentation/kmemleak.txt
@@ -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.
+
+Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug for supported
+architectures.
Usage
-----
On Fri, 10 Jun 2011 22:09:56 +0300 Maxin B John wrote:
> >> I think Daniel's suggestion is better, we don't have to worry about
> >> changing the documentation every time we add a new architecture.
> I agree with that.
>
> > Please send an updated patch without the currently-supported list
> > of architectures.
> Please find the updated patch below:
>
> Signed-off-by: Maxin B. John <[email protected]>
Applied, thanks.
> ---
> diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt
> index 090e6ee..51063e6 100644
> --- a/Documentation/kmemleak.txt
> +++ b/Documentation/kmemleak.txt
> @@ -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.
> +
> +Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug for supported
> +architectures.
>
> Usage
> -----
>
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Fri, Jun 10, 2011 at 09:18:38PM +0100, Randy Dunlap wrote:
> On Fri, 10 Jun 2011 22:09:56 +0300 Maxin B John wrote:
> > >> I think Daniel's suggestion is better, we don't have to worry about
> > >> changing the documentation every time we add a new architecture.
> > I agree with that.
> >
> > > Please send an updated patch without the currently-supported list
> > > of architectures.
> > Please find the updated patch below:
> >
> > Signed-off-by: Maxin B. John <[email protected]>
>
> Applied, thanks.
Thanks.
--
Catalin