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: Joseph Myers <joseph at codesourcery dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 18 Sep 2015 15:47:28 +0000
- 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>
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.
--
Joseph S. Myers
joseph@codesourcery.com