Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes

[Anshuman Khandual <khandual@linux.vnet.ibm.com>]

On 06/03/2016 03:56 AM, Cyril Bur wrote:
> On 1 June 2016 at 18:26, Anshuman Khandual <khandual@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.