Ananth N Mavinakayanahalli <[email protected]> wrote:
>
> The following patch (against 2.6.15-rc5-mm3) fixes a kprobes build
> break due to changes introduced in the kprobe locking in
> 2.6.15-rc5-mm3. In addition, the patch reverts back the open-coding
> of kprobe_mutex.
Complaints:
a) Your changelog failed to describe what the build breakage was. It helps.
b) the changelog fails to describe _why_ we've reverted the locking
c) The patch does multiple things.
See, what I would _like_ to do is to fold the fixes in this patch into the
patches which are already in -mm. That way, the patches which hit Linus's
tree will be neater and won't introduce build breakage at any point.
And they won't add stuff and then immediately take it away again. That's
for git losers ;)
But the patch which you've sent doesn't have a hope of applying anywhere
except at the end of the patches which I already have.
The net result is that we'll hit Linus's tree with a bunch of patches, and
then a followup patch which fixes those patches. Which is a dumb way in
which to present the permanent kernel record, given that we have an
opportunity to get it right first time, no?
Here's the bottom line: please never ever ever ever ever ever do more than
one thing in a single patch. Ever. Did I mention "ever"? There are soooo
many reasons for this....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
