Re: [PATCH 0/6] x86 tracehook patches

[Ingo Molnar <mingo@elte.hu>]

* Roland McGrath <roland@redhat.com> wrote:

> Hi!  Here is the x86 arch work that goes with the "tracehook" patch 
> series that I posted for the generic code.  I don't know how the 
> merging will go with that.  But when there is a tree containing all 
> that to base it on, you can merge these arch patches on top of that. 
> You can't take these without the generic tracehook series, some will 
> break the build until the generic file is there.
> 
> This series also requires as a baseline what you have in tip/x86/step.
> 
> The following changes since commit dc2cda6931dd54cd02b05da3a5bc969032e10992:
>   Roland McGrath (1):
>         x86 ptrace: user-sets-TF nits
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git x86-tracehook
> 
> Roland McGrath (6):
>       x86: tracehook_signal_handler
>       x86: tracehook syscall
>       x86: tracehook: asm/syscall.h
>       x86 signals: use asm/syscall.h
>       x86: tracehook: TIF_NOTIFY_RESUME
>       x86: tracehook: CONFIG_HAVE_ARCH_TRACEHOOK

since Andrew picked up the generic bits into -mm i cannot put the 
generic+x86 bits into -tip.

Andrew, could you please pick up these x86 bits as well?

  Reviewed-by: Ingo Molnar <mingo@elte.hu>

Roland, a sidenote: your sha1's did not match that of tip/x86/step.

It's not a big issue in this case because Andrew takes patches but best 
practice is to not rebase commits you base future pull requests on. 
(rebasing is fine until something is WIP and put pushed/pulled - but 
it's lethal to transparency and mergability once patches have been 
published, so we try to avoid it as much as possible)

The way you could rebase existing commits back ontop of x86/step is to 
do this in your tracehook branch:

   git-rebase -i --onto tip/x86/step linus/master

(and if you've got fixes for x86/step then please send them as a pull 
request that just adds the fix in an append-only manner.)

	Ingo