Paul Jackson <[email protected]> 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 [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]
