This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] powerpc: Update AT_HWCAP2 bits
Adhemerval Zanella <adhemerval.zanella@linaro.org> writes:
> On 19/10/2017 07:57, Florian Weimer wrote:
>> On 10/18/2017 09:15 PM, Tulio Magno Quites Machado Filho wrote:
>>> Linux commit ID XXXXXXXXX reserved a new bit for a scenario where
>>> transactional memory is available, but the suspended state is disabled.
>>
>> The semantics of this bit are wrong. If the suspended state is not available, the old hwcap bit needs to be cleared, and a new flag needs to be set which documents the availability of the different for, of transactional memory. Otherwise, old applications which assume the presence of the suspended state when the old hwcap bit is set will break.
>>
>> (I think we should have this discussion on the kernel list.)
I'd appreciate if we could follow Florian's suggestion and keep this
discussion in linuxppc-dev mailing list, with the authors of these patches
involved too. ;-)
For the record, the last version of the patch series is being reviewed at [1]
[2].
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-October/164701.html
[2] http://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=7773
> How exactly this kind of hardware handles the 'tsr.' instruction
> state change? Assuming the kernel submission proposal it seems
> an ABI extension, since MSR[TS] will be change from 0xb10 to 0b00
> in case of a transaction (instead of expected 0b10 to 0x01).
Indeed. It traps and aborts the transaction.
> Will it also execute the failure handling in this case, as for a
> 'tresume' in the case a failure in suspended state?
When suspend is not available, it will never enter suspended state.
> Also, will it also change TEXARS with the abort information?
It should, with a permanent error cause so that old applications entering
suspended state can adopt another technique.
> I completely agree with Florian here, this is as *ABI* change
> and the kernel need to advertise a different TM ABI instead
> of as an extension.
I'm forwarding your last question and this comment to linuxppc-dev and Cc'ing
you. Would you mind to elaborate what you're mean there, please?
By the way, you may want to read my reply to Florian there [3] before posting.
[3] https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-October/165124.html
Thank you all for these comments!
--
Tulio Magno