[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090609141323.aae795a9.akpm@linux-foundation.org>
Date: Tue, 9 Jun 2009 14:13:23 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Stefani Seibold <stefani@...bold.net>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [patch] proc.txt: Update kernel filesystem/proc.txt
documentation
On Tue, 09 Jun 2009 22:53:27 +0200
Stefani Seibold <stefani@...bold.net> wrote:
> Am Dienstag, den 09.06.2009, 12:36 -0700 schrieb Andrew Morton:
> > On Tue, 09 Jun 2009 12:35:58 +0200
> > Stefani Seibold <stefani@...bold.net> wrote:
> >
> > > This is a patch against the file Documentation/filesystem/proc.txt.
> > >
> > > It is an update for the "Process-Specific Subdirectories" to reflect
> > > the changes till kernel 2.6.30. It also introduce the my
> > > "provide stack information for threads".
> >
> > Sorry, but it would be much preferable to do this as two patches. The
> > first fixes up proc.txt and the second adds the
> > stack-information-for-threads material.
> >
>
> That is really frustrating. I did everything that you and ingo molnar
> had complained.
>
> What is wrong with the "provide stack information for threads"? It is a
> very tiny patch which did not harm.
>
> The only reason to fix and update the proc.txt was that you told me that
> this is the last thing that you miss.
It's more a procedural thing really. We've learnt that it's best to
avoid mixing more than a single "concept" into a single patch. For a
whole pile of reasons: reviewability, bisectability, revertability,
testability, etc.
In this case, it's unobvious which parts of the patch were specific to
the stack-information-for-threads changes and which parts were not.
This makes it hard to review your proposed changes.
> > This is because the two changes are quite conceptually distinct, and we
> > might end up wanting to merge one chage and not the other.
> >
>
> Okay, if the other patch will not included than it makes no sense for me
> to get in the other.
>
> Simple question: will you accept the thread stack info patch or not? If
> yes, i will spent the time to split proc.txt patch.
>
It looks OK to me now. If it passes testing and nobody has fatal
objections then yes, I expect it'll be merged in 2.6.31.
The way to organise these changes is
[patch 1/2] fix proc.txt
[patch 2/2] procfs: provide stack information for threads
The second patch will contain a small update to proc.txt.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists