[ENBD] Re: fr1 under Red Hat ES 3.0

[P.T. Breuer]

In article <200409212138.i8LLcN029685 at oboe.it.uc3m.es> you wrote:
> In article <41506E42.1080107 at free.fr> you wrote:
> > does anybody has ported fr1 under Red Hat 3.0 ES ? (kernel 
> > kernel-2.4.21-20.EL 
> > <https://rhn.redhat.com/network/software/packages/details.pxt?sid=1004929978&id_combo=500000341%7c237506>, 

> That takes me to a signin page.

> > yes !! but modified by redhat !!! oh no !!!)

> I think you're making a fuss about not very much here. Show me which of
> the hunks in the patch fails to apply, and the section of code it fails
> to apply to, and I'm sure the problem will resolve itself.

OK, J-M has been kind enough to supply me with the RH files, and I can
say that the changes made by RH are (apparently) confined to md.c, and
they have no semantic influence.

This is for the "record".

The current fr1 patch fails for RH on two hunks, the last two of the
patch.  The failure each time is because RH have mesed with the context
that the patch needs to see in order to locate where to make its
change.

In the first hunk, the patch context does not match because RH have
removed the line reading

       current->nice = 19;

(and the empty line after it) in the code that says what to do when 
resync starts going faster than the specified minimum resync speed. RH
apparently don't want the priority of the resync thread to change at
all, let alone to drop to bottom priority. I don't know why.

This minor change in the RH code should stop no human being on earth
from applying that patch hunk by hand.  It is still evident where the
hunk should go (about line 3850) from other bits of the included
context, such as part of a comment (unique in the file) and other bits
of matching code.

However, I can't easily do anything about it in terms of changing the
patch, because the RH spurious-line-removal is right at the point where
I want to apply the throttle-control part of the patch. I'll
investigate, however.


In the second hunk that fails, the failure is due to RH adding right at
the end of the file two extra EXPORT_SYMBOL declarations. Since I also
want to add an EXPORT_SYMBOL and neither of us cares where the
declaration is made, I can avoid hitting their changed context by
moving the hunk application point slightly, about three lines higher
up, or by moving it to halfway through the file.

The question is whether I should, since the problem is really evident to
the naked eye so I don't see why a human being should have trouble
adding that hunk by hand too. Adding extra exports at the end of the file
is the polite thing to do, and both RH and I have been polite.

Suggestions?

Peter