On 06/03/2016 03:56 AM, Cyril Bur wrote: > On 1 June 2016 at 18:26, Anshuman Khandual <khand...@linux.vnet.ibm.com> > wrote: > >> On 05/31/2016 04:42 AM, Michael Ellerman wrote: >>> Hi Laurent, >>> >>> Sorry no. My next branch closed for 4.7 about 3 weeks ago. >>> >>> This series has been blocked for a long time on the gdb support, but >> that is >>> now working. However it still doesn't pass its own selftests, and I had >> some >> >> This series was clearing all of the selftests at the time it was posted. >> But yes, it has some assumptions from timing and sync perspective which >> gets broken some times as the kernel changes. Its been bit difficult to >> perfect the sync requirements as we can do only some much inside the >> transaction once it gets started. There are scopes here to improve these >> selftests but not clearing them today does not really mean the patches are >> now functionally broken. >> >>> disagreements with the implementation - it duplicates a lot of code >> rather >>> than refactoring things. >> >> hmm, sorry, I dont remember the context here. Can you please point to the >> discussion in this regard ? >> >>> >>> I'm waiting on a patch from Cyril which will rework how the TM FP state >> is >>> handled, and that should make this series easier to implement. >> >> Can you please elaborate on this ? Has this patch been posted in the >> mailing >> list ? How does this make it easier for us to implement these ELF notes ? > > > Hi Anshuman, > > I'm doing a bit of a rewrite of the TM handling of the FP/VMX/VSX state. > > At the moment is is rather confusing since pt_regs is the always the 'live' > state > and theres a ckpt_regs that is the pt_regs for the checkpointed state. > FPU/VMX/VSX > is done differently which is really only creating confusion so I'm changing > it to do the > same at for pt_regs/ckpt_regs. Ultimately this is part of more work from me
But that changes the basic semantics on which this ptrace series is written. With this change, a significant part of the ptrace series has to be changed. Its just an improvement on how we store running and check pointed values for FP/VSX/VMX registers inside the kernel. How does it improve ptrace interface from the user point of view ? If not, then why this change is necessary for the acceptance of this patch series ? This change should be implemented as an independent work and then necessary ptrace change can be incorporated there after. > but > Michael has told me that at least this bit is useful now so I'm splitting > it off from > the bigger picture and sending asap. At the very least it will make it > easier to know > what and where the transactional state it and where the checkpointed state > is. > > It isn't on the list but I hope I'll get it out today. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
