This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 00/10] nptl: Fix Race conditions in pthread cancellation (BZ#12683)
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 18 Sep 2015 17:29:15 -0300
- Subject: Re: [PATCH 00/10] nptl: Fix Race conditions in pthread cancellation (BZ#12683)
- Authentication-results: sourceware.org; auth=none
- References: <55FB1CA0 dot 2 at linaro dot org> <alpine dot DEB dot 2 dot 10 dot 1509172032090 dot 2455 at digraph dot polyomino dot org dot uk> <alpine dot DEB dot 2 dot 10 dot 1509172102550 dot 2455 at digraph dot polyomino dot org dot uk> <55FC0E80 dot 5000404 at linaro dot org> <alpine dot DEB dot 2 dot 10 dot 1509181545030 dot 11870 at digraph dot polyomino dot org dot uk>
On 18-09-2015 12:47, Joseph Myers wrote:
> On Fri, 18 Sep 2015, Adhemerval Zanella wrote:
>
>>> To the extent that the
>>> patches will all go in one commit anyway, could you use a division into
>>> patches that more logically reflects the different parts of the change.
>>> (To the extent that patches can go in separate commits - Phil Blundell's
>>> new tests come to mind, unless there's some reason they depend on other
>>> changes - they should be posted and reviewed separately so they can go in
>>> before the rest of the patch series.)
>>>
>>
>> Ok, I will create a patch to include Phil's new testscase. For the rest of
>> patchset since it require very internal changes I see the architecture
>> approach of fixing each one with one patch a better approach than add
>> platform neutral patches that let the tree broken for all architectures.
>
> As the *commit* organization, yes, the bulk of the
> architecture-independent changes should go in the same commit as the fixes
> for as many architectures as possible.
>
> As the *patch posting* organization, however, that means you can split the
> patches for posting in whatever way is most convenient for the reader
> without regard to whether the state of the tree after some subset of the
> patches is internally consistent or works on a particular architecture.
> Which means that the powerpc64 patch contains only powerpc64 changes, for
> example, not the architecture-specific changes, and the i386 changes go in
> the i386 patch, not the powerpc32 patch even if it depends on some of
> them.
>
I do understand your point however I must argue this will require more work
(reorganize the code itself) that will not generate prior benefit. What I
think it will more feasible is split the powerpc64 patch in NPTL and general
code first then powerpc64 bits and then put i386 before powerpc32. Would it
be convenient for the reader?