lkml.org 
[lkml]   [2010]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC PATCH 14/43] ptrace, frv: change signature of arch_ptrace()
Date
David Howells <dhowells@redhat.com> writes:
> Namhyung Kim <namhyung@gmail.com> wrote:
>> I just wanted to let you know it depends on that.
>
> The patch being part of the series is probably sufficient, though a note of
> the subject line of the previous patch would be useful.
>

I see. Will do that hereafter.


>> What is the proper way to handle this?
>
> A summary of the changes being made is good:
>
> ptrace: Fix up the arguments arch_ptrace() in arch FRV
>
> Fix up the arguments to arch_ptrace() to take account of the fact that
> addr and data are now unsigned long rather than long as of a preceding
> patch in this series.
>
> Signed-off-by: ...
>

Thanks. I will use this on the next round. :-)


> Note, however, that if the earlier patch breaks the compilation and then this
> patch fixes it up, you should roll this patch into the earlier patch, and the
> earlier patch is not complete without it.
>
> Think what happens if patch 3/43 breaks an arch, and then patch 43/43, say,
> mends that arch, and then bisection lands on patch 3 during its progress. You
> may end up having to 'git bisect skip' all the patches between 3 and 43 one at
> a time.
>

In this series, 3/43 changes the prototype of arch_ptrace() in
include/linux/ptrace.h and the following patches change it for each arch in
arch/xxx/kernel/ptrace.c. Do you mean all of arch change patches should be
combinded into a patch?

--
Regards,
Namhyung Kim


\
 
 \ /
  Last update: 2010-08-27 15:01    [W:0.151 / U:0.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site