Messages in this thread | | | Date | Sun, 4 Dec 2005 00:15:25 -0800 | From | Andrew Morton <> | Subject | Re: How do I remove a patch buried in your *-mm series? |
| |
Paul Jackson <pj@sgi.com> wrote: > > I want to remove the patch in *-mm: > > 1) cpuset-change-marker-for-relative-numbering.patch > > Unfortunately, it collides with another couple cpuset patches later in > your stack: > > 2) cpuset-memory-pressure-meter.patch, cpuset-memory-pressure-meter-gcc-295-fix.patch > > How should I do this so I minimize the amount of cussing you do in my > general direction: > > A. Just ask you to nuke patch (1) above; let you edit the mess. > B. Ask you to nuke both (1) and (2); leave me to resend a (2) that applies. > C. Send a reversing patch that applies on top of your current *-mm stack. > D. Some other plan you would prefer.
E. You send a _minimal_ patch against lastest mm, telling me "this fixes a bug in cpuset-change-marker-for-relative-numbering.patch". Then I insert it into the series with name cpuset-change-marker-for-relative-numbering-fix.patch and it gets folded into cpuset-change-marker-for-relative-numbering.patch prior to going to Linus.
Usually people forget to tell me which patch it fixes, but I work it out.
In this case, dropping cpuset-change-marker-for-relative-numbering.patch works fine too - it took 20 seconds to fix up the rejects. Mainly by simply omitting them, because all this stuff:
*************** *** 191,199 **** .cpus_allowed = CPU_MASK_ALL, .mems_allowed = NODE_MASK_ALL, .marker_pid = 0, - .fmeter.cnt = 0, - .fmeter.val = 0, - .fmeter.time = 0, .count = ATOMIC_INIT(0), .sibling = LIST_HEAD_INIT(top_cpuset.sibling), .children = LIST_HEAD_INIT(top_cpuset.children), --- 191,201 ---- .cpus_allowed = CPU_MASK_ALL, .mems_allowed = NODE_MASK_ALL, .marker_pid = 0, + .fmeter = { + .cnt = 0, + .val = 0, + .time = 0, + }, .count = ATOMIC_INIT(0), .sibling = LIST_HEAD_INIT(top_cpuset.sibling), .children = LIST_HEAD_INIT(top_cpuset.children),
It just redundant - the compiler does that.
> I have verified that removing all the patches above applies cleanly and > builds, with just a harmless -74 lines offset on one of the remaining > cpuset patches. > > So I recommend B.
Your call. E is preferred though. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |