Patches are on top of the -tip/master tree.
First patch in the series reverts the first version of the patch that went into
the -tip tree.
Changes from v1:
a. Split the patch into multiple patches.
b. Fix some bugs and coding style changes based on Roland's feedback.
c. Add generic PTRACE_GETREGSET/PTRACE_SETREGSET commands through which we can
export the architecture specific regsets using the corresponding
NT_* codes that userland is already aware of. The "xstate" regset is exported
only using this interface.
thanks,
suresh
> Patches are on top of the -tip/master tree.
> First patch in the series reverts the first version of the patch that went into
> the -tip tree.
AFAIK tip/x86/ptrace is just a temporary branch containing nothing but your
patch. So I imagine you don't need a reversion, Ingo et al will just put
the new patches on a fresh replacement branch.
I'll reply to each patch individually.
Thanks,
Roland
On Tue, 2010-02-09 at 17:12 -0800, Roland McGrath wrote:
> > Patches are on top of the -tip/master tree.
> > First patch in the series reverts the first version of the patch that went into
> > the -tip tree.
>
> AFAIK tip/x86/ptrace is just a temporary branch containing nothing but your
> patch. So I imagine you don't need a reversion, Ingo et al will just put
> the new patches on a fresh replacement branch.
That is my understanding too but was not sure. Wanted to mention that
they should either replace the branch or apply the reverted patch
(incase if they have issues with replacing the branch). Peter, you seem
to have applied the revert. Can you instead start with a fresh branch so
that we can just ignore the first version (and hence skip first revert
patch in this series)?
> I'll reply to each patch individually.
Thanks Roland.
* Roland McGrath <[email protected]> wrote:
> > Patches are on top of the -tip/master tree. First patch in the series
> > reverts the first version of the patch that went into the -tip tree.
>
> AFAIK tip/x86/ptrace is just a temporary branch containing nothing but your
> patch. So I imagine you don't need a reversion, Ingo et al will just put
> the new patches on a fresh replacement branch.
Yeah - and the patches your review strikes we'll remove/fix as well. And you
can pick up the patches yourself as well into your tree, if you wish to. (or
pull it from us if we are done) We can push it too with your acks - your
call.
> I'll reply to each patch individually.
Thanks!
Ingo
> Yeah - and the patches your review strikes we'll remove/fix as well. And you
> can pick up the patches yourself as well into your tree, if you wish to. (or
> pull it from us if we are done) We can push it too with your acks - your
> call.
AFAIK there is no tree of mine that anyone habitually pulls from as part of
a regular merge procedure. Since the x86 patches have to go through your
approval, and these ones are coming from someone else's postings (Suresh),
I'm not sure how I would or should fit into the chain. If you would like
me to use a git branch for x86 things (ptrace things? x86 ptrace things?)
that have my ACK and I think should be merged, I'm glad to do that.
Thanks,
Roland
On 02/10/2010 10:58 AM, Roland McGrath wrote:
>> Yeah - and the patches your review strikes we'll remove/fix as well. And you
>> can pick up the patches yourself as well into your tree, if you wish to. (or
>> pull it from us if we are done) We can push it too with your acks - your
>> call.
>
> AFAIK there is no tree of mine that anyone habitually pulls from as part of
> a regular merge procedure. Since the x86 patches have to go through your
> approval, and these ones are coming from someone else's postings (Suresh),
> I'm not sure how I would or should fit into the chain. If you would like
> me to use a git branch for x86 things (ptrace things? x86 ptrace things?)
> that have my ACK and I think should be merged, I'm glad to do that.
>
We're happy to carry the patches as long as it's okay with you. We were
mostly wondering if you preferred any other kind of workflow.
-hpa
> We're happy to carry the patches as long as it's okay with you. We were
> mostly wondering if you preferred any other kind of workflow.
When I write patches myself, I always use git, so it is always easy and
most convenient for me to have my own branches pulled directly just to
save on 'git rebase' churn later.
As to a regular workflow of using a well-known branch of mine, I think it
makes sense for me to maintain a branch if there is an area where things
are presumptively merged just on my approval and I'm the one who has to be
lobbied to revert them. I have not heretofore acquired the sensation that
this was the case with any given area of code.
Thanks,
Roland
On 02/10/2010 07:45 PM, Roland McGrath wrote:
>> We're happy to carry the patches as long as it's okay with you. We were
>> mostly wondering if you preferred any other kind of workflow.
>
> When I write patches myself, I always use git, so it is always easy and
> most convenient for me to have my own branches pulled directly just to
> save on 'git rebase' churn later.
>
> As to a regular workflow of using a well-known branch of mine, I think it
> makes sense for me to maintain a branch if there is an area where things
> are presumptively merged just on my approval and I'm the one who has to be
> lobbied to revert them. I have not heretofore acquired the sensation that
> this was the case with any given area of code.
LOL, okay :)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.